Issue with the sub-content tag in Screen Definitions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with the sub-content tag in Screen Definitions

Tim Ruppert
All, we've been using the content manager for many of our  
applications over the past year.  Recently, I had a client come back  
for some follow on work and when I went to deploy the app on my dev  
server, I realized there was a problem with the lookup service.  In  
hopes that this will be more clear - here's the full scenario.

In my Content Manager,

1. I create a top level piece of content called something like  
WebSite Root with the following parameters:
-- Document
-- Content Name - WebSite Root

2. I then create a DataResource with the following parameters:
-- Type Id - Long Text
-- Locale - en_US
-- Resource Name - Home Body
-- MIME Type Id - text/html
-- is Public - Y
-- Fill out Electronic Text

3. I then create a Content Instance with the following parameters:
-- Document
-- Content Name - Home Body
-- Locale - en_US
-- MIME Type - text/html

4. Then I go to the WebSite Root Content Object and Add an associated  
piece of content:
-- Content ID to - ID of Content Instance that is Home Body
-- Content Assoc Type Id - Sub Section
-- Map Key (Very Important - or at least it used to be) - Home Body

So, I also created a new decorator that had a decorator-section-
include called sidebar and one called body.  Here's my Screen file  
that worked great as of August of this year:

     <screen name="Home">
         <section>
             <actions>
                 <set field="leftbarScreenName" value="leftbar"/>
                 <set field="MainColumnStyle" value="center"/>
                 <set field="title-property" value="Home"/>
             </actions>
             <widgets>
                 <decorator-screen name="content-decorator"  
location="${parameters.mainDecoratorLocation}">
                     <decorator-section name="sidebar">
                         <sub-content content-id="10001" assoc-
name="Home Sidebar" />
                     </decorator-section>
                     <decorator-section name="body">
                         <sub-content content-id="10001" assoc-
name="Home" />
                     </decorator-section>
                 </decorator-screen>
             </widgets>
         </section>
     </screen>

The effect that I'm seeing now is that EVERY single page - regardless  
of what is put in the assoc-name - always just shows the very first  
association.   It doesn't matter if you have one piece associated or  
50 - each entry on each page that uses this lookup style always gets  
the same response.

Has anyone committed anything that would potentially have changed the  
behavior of this module?

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

Scott Gray
Hi Tim

I don't know much about content but it looks like there where some
changes made to ContentWorker.java and I seem to recall a conversation
about it on the list, something to do with from and to associations of
sub content.

Regards
Scott

Tim Ruppert wrote:

> All, we've been using the content manager for many of our applications
> over the past year.  Recently, I had a client come back for some
> follow on work and when I went to deploy the app on my dev server, I
> realized there was a problem with the lookup service.  In hopes that
> this will be more clear - here's the full scenario.
>
> In my Content Manager,
>
> 1. I create a top level piece of content called something like WebSite
> Root with the following parameters:
> -- Document
> -- Content Name - WebSite Root
>
> 2. I then create a DataResource with the following parameters:
> -- Type Id - Long Text
> -- Locale - en_US
> -- Resource Name - Home Body
> -- MIME Type Id - text/html
> -- is Public - Y
> -- Fill out Electronic Text
>
> 3. I then create a Content Instance with the following parameters:
> -- Document
> -- Content Name - Home Body
> -- Locale - en_US
> -- MIME Type - text/html
>
> 4. Then I go to the WebSite Root Content Object and Add an associated
> piece of content:
> -- Content ID to - ID of Content Instance that is Home Body
> -- Content Assoc Type Id - Sub Section
> -- Map Key (Very Important - or at least it used to be) - Home Body
>
> So, I also created a new decorator that had a
> decorator-section-include called sidebar and one called body.  Here's
> my Screen file that worked great as of August of this year:
>
>     <screen name="Home">
>         <section>
>             <actions>
>                 <set field="leftbarScreenName" value="leftbar"/>
>                 <set field="MainColumnStyle" value="center"/>
>                 <set field="title-property" value="Home"/>
>             </actions>
>             <widgets>
>                 <decorator-screen name="content-decorator"
> location="${parameters.mainDecoratorLocation}">
>                     <decorator-section name="sidebar">
>                         <sub-content content-id="10001"
> assoc-name="Home Sidebar" />
>                     </decorator-section>
>                     <decorator-section name="body">
>                         <sub-content content-id="10001"
> assoc-name="Home" />
>                     </decorator-section>
>                 </decorator-screen>
>             </widgets>
>         </section>
>     </screen>
>
> The effect that I'm seeing now is that EVERY single page - regardless
> of what is put in the assoc-name - always just shows the very first
> association.   It doesn't matter if you have one piece associated or
> 50 - each entry on each page that uses this lookup style always gets
> the same response.
>
> Has anyone committed anything that would potentially have changed the
> behavior of this module?
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

Tim Ruppert
Thanks for the quick response Scott - I remember that as well from  
when Al was doing some work with this earlier in December.  I know  
that David had some thoughts on the way that it was all pieced  
together as well.

David, Al, at a quick glance, do you think that the changes that we  
discussed could have caused this feature to no longer work?

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 5, 2007, at 9:47 PM, Scott Gray wrote:

> Hi Tim
>
> I don't know much about content but it looks like there where some  
> changes made to ContentWorker.java and I seem to recall a  
> conversation about it on the list, something to do with from and to  
> associations of sub content.
>
> Regards
> Scott
>
> Tim Ruppert wrote:
>> All, we've been using the content manager for many of our  
>> applications over the past year.  Recently, I had a client come  
>> back for some follow on work and when I went to deploy the app on  
>> my dev server, I realized there was a problem with the lookup  
>> service.  In hopes that this will be more clear - here's the full  
>> scenario.
>>
>> In my Content Manager,
>>
>> 1. I create a top level piece of content called something like  
>> WebSite Root with the following parameters:
>> -- Document
>> -- Content Name - WebSite Root
>>
>> 2. I then create a DataResource with the following parameters:
>> -- Type Id - Long Text
>> -- Locale - en_US
>> -- Resource Name - Home Body
>> -- MIME Type Id - text/html
>> -- is Public - Y
>> -- Fill out Electronic Text
>>
>> 3. I then create a Content Instance with the following parameters:
>> -- Document
>> -- Content Name - Home Body
>> -- Locale - en_US
>> -- MIME Type - text/html
>>
>> 4. Then I go to the WebSite Root Content Object and Add an  
>> associated piece of content:
>> -- Content ID to - ID of Content Instance that is Home Body
>> -- Content Assoc Type Id - Sub Section
>> -- Map Key (Very Important - or at least it used to be) - Home Body
>>
>> So, I also created a new decorator that had a decorator-section-
>> include called sidebar and one called body.  Here's my Screen file  
>> that worked great as of August of this year:
>>
>>     <screen name="Home">
>>         <section>
>>             <actions>
>>                 <set field="leftbarScreenName" value="leftbar"/>
>>                 <set field="MainColumnStyle" value="center"/>
>>                 <set field="title-property" value="Home"/>
>>             </actions>
>>             <widgets>
>>                 <decorator-screen name="content-decorator"  
>> location="${parameters.mainDecoratorLocation}">
>>                     <decorator-section name="sidebar">
>>                         <sub-content content-id="10001" assoc-
>> name="Home Sidebar" />
>>                     </decorator-section>
>>                     <decorator-section name="body">
>>                         <sub-content content-id="10001" assoc-
>> name="Home" />
>>                     </decorator-section>
>>                 </decorator-screen>
>>             </widgets>
>>         </section>
>>     </screen>
>>
>> The effect that I'm seeing now is that EVERY single page -  
>> regardless of what is put in the assoc-name - always just shows  
>> the very first association.   It doesn't matter if you have one  
>> piece associated or 50 - each entry on each page that uses this  
>> lookup style always gets the same response.
>>
>> Has anyone committed anything that would potentially have changed  
>> the behavior of this module?
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

David E Jones-2

I don't see much value in speculation on this one. The initial from/
to change was months ago and required to get this working in the  
first place.

There has been more recent discussion about other areas of the code,  
mostly for writing content and not rendering, but I don't think that  
work (being done by Al) has gone back in yet.

The first step is to create a test case that fails for easy  
reproduction of the issues, like the CommonScreens.xml#policies screen.

I'll look into this a bit more.

-David


On Jan 5, 2007, at 9:55 PM, Tim Ruppert wrote:

> Thanks for the quick response Scott - I remember that as well from  
> when Al was doing some work with this earlier in December.  I know  
> that David had some thoughts on the way that it was all pieced  
> together as well.
>
> David, Al, at a quick glance, do you think that the changes that we  
> discussed could have caused this feature to no longer work?
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Jan 5, 2007, at 9:47 PM, Scott Gray wrote:
>
>> Hi Tim
>>
>> I don't know much about content but it looks like there where some  
>> changes made to ContentWorker.java and I seem to recall a  
>> conversation about it on the list, something to do with from and  
>> to associations of sub content.
>>
>> Regards
>> Scott
>>
>> Tim Ruppert wrote:
>>> All, we've been using the content manager for many of our  
>>> applications over the past year.  Recently, I had a client come  
>>> back for some follow on work and when I went to deploy the app on  
>>> my dev server, I realized there was a problem with the lookup  
>>> service.  In hopes that this will be more clear - here's the full  
>>> scenario.
>>>
>>> In my Content Manager,
>>>
>>> 1. I create a top level piece of content called something like  
>>> WebSite Root with the following parameters:
>>> -- Document
>>> -- Content Name - WebSite Root
>>>
>>> 2. I then create a DataResource with the following parameters:
>>> -- Type Id - Long Text
>>> -- Locale - en_US
>>> -- Resource Name - Home Body
>>> -- MIME Type Id - text/html
>>> -- is Public - Y
>>> -- Fill out Electronic Text
>>>
>>> 3. I then create a Content Instance with the following parameters:
>>> -- Document
>>> -- Content Name - Home Body
>>> -- Locale - en_US
>>> -- MIME Type - text/html
>>>
>>> 4. Then I go to the WebSite Root Content Object and Add an  
>>> associated piece of content:
>>> -- Content ID to - ID of Content Instance that is Home Body
>>> -- Content Assoc Type Id - Sub Section
>>> -- Map Key (Very Important - or at least it used to be) - Home Body
>>>
>>> So, I also created a new decorator that had a decorator-section-
>>> include called sidebar and one called body.  Here's my Screen  
>>> file that worked great as of August of this year:
>>>
>>>     <screen name="Home">
>>>         <section>
>>>             <actions>
>>>                 <set field="leftbarScreenName" value="leftbar"/>
>>>                 <set field="MainColumnStyle" value="center"/>
>>>                 <set field="title-property" value="Home"/>
>>>             </actions>
>>>             <widgets>
>>>                 <decorator-screen name="content-decorator"  
>>> location="${parameters.mainDecoratorLocation}">
>>>                     <decorator-section name="sidebar">
>>>                         <sub-content content-id="10001" assoc-
>>> name="Home Sidebar" />
>>>                     </decorator-section>
>>>                     <decorator-section name="body">
>>>                         <sub-content content-id="10001" assoc-
>>> name="Home" />
>>>                     </decorator-section>
>>>                 </decorator-screen>
>>>             </widgets>
>>>         </section>
>>>     </screen>
>>>
>>> The effect that I'm seeing now is that EVERY single page -  
>>> regardless of what is put in the assoc-name - always just shows  
>>> the very first association.   It doesn't matter if you have one  
>>> piece associated or 50 - each entry on each page that uses this  
>>> lookup style always gets the same response.
>>>
>>> Has anyone committed anything that would potentially have changed  
>>> the behavior of this module?
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>>
>>>
>>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

David E Jones-2
In reply to this post by Tim Ruppert

Okay, I just did a quick little test and based on this have multiple  
sub-content elements on a single page appears to be working fine. The  
changes to test this are in SVN rev 493431.

To test it just update, run "ant run-install" to get the new data in,  
and then go to the /ecommerce/control/policies page.

I guess we'll have to look into details a bit more on our side Tim.

-David


On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:

> All, we've been using the content manager for many of our  
> applications over the past year.  Recently, I had a client come  
> back for some follow on work and when I went to deploy the app on  
> my dev server, I realized there was a problem with the lookup  
> service.  In hopes that this will be more clear - here's the full  
> scenario.
>
> In my Content Manager,
>
> 1. I create a top level piece of content called something like  
> WebSite Root with the following parameters:
> -- Document
> -- Content Name - WebSite Root
>
> 2. I then create a DataResource with the following parameters:
> -- Type Id - Long Text
> -- Locale - en_US
> -- Resource Name - Home Body
> -- MIME Type Id - text/html
> -- is Public - Y
> -- Fill out Electronic Text
>
> 3. I then create a Content Instance with the following parameters:
> -- Document
> -- Content Name - Home Body
> -- Locale - en_US
> -- MIME Type - text/html
>
> 4. Then I go to the WebSite Root Content Object and Add an  
> associated piece of content:
> -- Content ID to - ID of Content Instance that is Home Body
> -- Content Assoc Type Id - Sub Section
> -- Map Key (Very Important - or at least it used to be) - Home Body
>
> So, I also created a new decorator that had a decorator-section-
> include called sidebar and one called body.  Here's my Screen file  
> that worked great as of August of this year:
>
>     <screen name="Home">
>         <section>
>             <actions>
>                 <set field="leftbarScreenName" value="leftbar"/>
>                 <set field="MainColumnStyle" value="center"/>
>                 <set field="title-property" value="Home"/>
>             </actions>
>             <widgets>
>                 <decorator-screen name="content-decorator"  
> location="${parameters.mainDecoratorLocation}">
>                     <decorator-section name="sidebar">
>                         <sub-content content-id="10001" assoc-
> name="Home Sidebar" />
>                     </decorator-section>
>                     <decorator-section name="body">
>                         <sub-content content-id="10001" assoc-
> name="Home" />
>                     </decorator-section>
>                 </decorator-screen>
>             </widgets>
>         </section>
>     </screen>
>
> The effect that I'm seeing now is that EVERY single page -  
> regardless of what is put in the assoc-name - always just shows the  
> very first association.   It doesn't matter if you have one piece  
> associated or 50 - each entry on each page that uses this lookup  
> style always gets the same response.
>
> Has anyone committed anything that would potentially have changed  
> the behavior of this module?
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

byersa
I think this will all come under the current tasks to clean up the content
manager. I will be looking at it in the next day or so.

-Al

On 1/6/07, David E Jones <[hidden email]> wrote:

>
>
> Okay, I just did a quick little test and based on this have multiple
> sub-content elements on a single page appears to be working fine. The
> changes to test this are in SVN rev 493431.
>
> To test it just update, run "ant run-install" to get the new data in,
> and then go to the /ecommerce/control/policies page.
>
> I guess we'll have to look into details a bit more on our side Tim.
>
> -David
>
>
> On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:
>
> > All, we've been using the content manager for many of our
> > applications over the past year.  Recently, I had a client come
> > back for some follow on work and when I went to deploy the app on
> > my dev server, I realized there was a problem with the lookup
> > service.  In hopes that this will be more clear - here's the full
> > scenario.
> >
> > In my Content Manager,
> >
> > 1. I create a top level piece of content called something like
> > WebSite Root with the following parameters:
> > -- Document
> > -- Content Name - WebSite Root
> >
> > 2. I then create a DataResource with the following parameters:
> > -- Type Id - Long Text
> > -- Locale - en_US
> > -- Resource Name - Home Body
> > -- MIME Type Id - text/html
> > -- is Public - Y
> > -- Fill out Electronic Text
> >
> > 3. I then create a Content Instance with the following parameters:
> > -- Document
> > -- Content Name - Home Body
> > -- Locale - en_US
> > -- MIME Type - text/html
> >
> > 4. Then I go to the WebSite Root Content Object and Add an
> > associated piece of content:
> > -- Content ID to - ID of Content Instance that is Home Body
> > -- Content Assoc Type Id - Sub Section
> > -- Map Key (Very Important - or at least it used to be) - Home Body
> >
> > So, I also created a new decorator that had a decorator-section-
> > include called sidebar and one called body.  Here's my Screen file
> > that worked great as of August of this year:
> >
> >     <screen name="Home">
> >         <section>
> >             <actions>
> >                 <set field="leftbarScreenName" value="leftbar"/>
> >                 <set field="MainColumnStyle" value="center"/>
> >                 <set field="title-property" value="Home"/>
> >             </actions>
> >             <widgets>
> >                 <decorator-screen name="content-decorator"
> > location="${parameters.mainDecoratorLocation}">
> >                     <decorator-section name="sidebar">
> >                         <sub-content content-id="10001" assoc-
> > name="Home Sidebar" />
> >                     </decorator-section>
> >                     <decorator-section name="body">
> >                         <sub-content content-id="10001" assoc-
> > name="Home" />
> >                     </decorator-section>
> >                 </decorator-screen>
> >             </widgets>
> >         </section>
> >     </screen>
> >
> > The effect that I'm seeing now is that EVERY single page -
> > regardless of what is put in the assoc-name - always just shows the
> > very first association.   It doesn't matter if you have one piece
> > associated or 50 - each entry on each page that uses this lookup
> > style always gets the same response.
> >
> > Has anyone committed anything that would potentially have changed
> > the behavior of this module?
> >
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> >
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

David E Jones-2

Al,

I wouldn't worry about it. As mentioned in my later reply to this,  
the problem appears to be something specific to this the custom use  
of this as the demo/test stuff I threw into OFBiz seems to be working  
fine (ie the updated policies page in ecommerce).

-David


On Jan 6, 2007, at 3:08 AM, Al Byers wrote:

> I think this will all come under the current tasks to clean up the  
> content
> manager. I will be looking at it in the next day or so.
>
> -Al
>
> On 1/6/07, David E Jones <[hidden email]> wrote:
>>
>>
>> Okay, I just did a quick little test and based on this have multiple
>> sub-content elements on a single page appears to be working fine. The
>> changes to test this are in SVN rev 493431.
>>
>> To test it just update, run "ant run-install" to get the new data in,
>> and then go to the /ecommerce/control/policies page.
>>
>> I guess we'll have to look into details a bit more on our side Tim.
>>
>> -David
>>
>>
>> On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:
>>
>> > All, we've been using the content manager for many of our
>> > applications over the past year.  Recently, I had a client come
>> > back for some follow on work and when I went to deploy the app on
>> > my dev server, I realized there was a problem with the lookup
>> > service.  In hopes that this will be more clear - here's the full
>> > scenario.
>> >
>> > In my Content Manager,
>> >
>> > 1. I create a top level piece of content called something like
>> > WebSite Root with the following parameters:
>> > -- Document
>> > -- Content Name - WebSite Root
>> >
>> > 2. I then create a DataResource with the following parameters:
>> > -- Type Id - Long Text
>> > -- Locale - en_US
>> > -- Resource Name - Home Body
>> > -- MIME Type Id - text/html
>> > -- is Public - Y
>> > -- Fill out Electronic Text
>> >
>> > 3. I then create a Content Instance with the following parameters:
>> > -- Document
>> > -- Content Name - Home Body
>> > -- Locale - en_US
>> > -- MIME Type - text/html
>> >
>> > 4. Then I go to the WebSite Root Content Object and Add an
>> > associated piece of content:
>> > -- Content ID to - ID of Content Instance that is Home Body
>> > -- Content Assoc Type Id - Sub Section
>> > -- Map Key (Very Important - or at least it used to be) - Home Body
>> >
>> > So, I also created a new decorator that had a decorator-section-
>> > include called sidebar and one called body.  Here's my Screen file
>> > that worked great as of August of this year:
>> >
>> >     <screen name="Home">
>> >         <section>
>> >             <actions>
>> >                 <set field="leftbarScreenName" value="leftbar"/>
>> >                 <set field="MainColumnStyle" value="center"/>
>> >                 <set field="title-property" value="Home"/>
>> >             </actions>
>> >             <widgets>
>> >                 <decorator-screen name="content-decorator"
>> > location="${parameters.mainDecoratorLocation}">
>> >                     <decorator-section name="sidebar">
>> >                         <sub-content content-id="10001" assoc-
>> > name="Home Sidebar" />
>> >                     </decorator-section>
>> >                     <decorator-section name="body">
>> >                         <sub-content content-id="10001" assoc-
>> > name="Home" />
>> >                     </decorator-section>
>> >                 </decorator-screen>
>> >             </widgets>
>> >         </section>
>> >     </screen>
>> >
>> > The effect that I'm seeing now is that EVERY single page -
>> > regardless of what is put in the assoc-name - always just shows the
>> > very first association.   It doesn't matter if you have one piece
>> > associated or 50 - each entry on each page that uses this lookup
>> > style always gets the same response.
>> >
>> > Has anyone committed anything that would potentially have changed
>> > the behavior of this module?
>> >
>> > Cheers,
>> > Tim
>> > --
>> > Tim Ruppert
>> > HotWax Media
>> > http://www.hotwaxmedia.com
>> >
>> > o:801.649.6594
>> > f:801.649.6595
>> >
>> >
>>
>>
>>
>>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

Tim Ruppert
All, this has been solved - and I was right in my assumptions - the  
attribute name "assoc-name" did change somewhere along the line to  
"map-key" - which makes more sense anyways.

Thanks to anyone who dug in there and looked to see if they'd made  
any changes.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 6, 2007, at 3:10 AM, David E Jones wrote:

>
> Al,
>
> I wouldn't worry about it. As mentioned in my later reply to this,  
> the problem appears to be something specific to this the custom use  
> of this as the demo/test stuff I threw into OFBiz seems to be  
> working fine (ie the updated policies page in ecommerce).
>
> -David
>
>
> On Jan 6, 2007, at 3:08 AM, Al Byers wrote:
>
>> I think this will all come under the current tasks to clean up the  
>> content
>> manager. I will be looking at it in the next day or so.
>>
>> -Al
>>
>> On 1/6/07, David E Jones <[hidden email]> wrote:
>>>
>>>
>>> Okay, I just did a quick little test and based on this have multiple
>>> sub-content elements on a single page appears to be working fine.  
>>> The
>>> changes to test this are in SVN rev 493431.
>>>
>>> To test it just update, run "ant run-install" to get the new data  
>>> in,
>>> and then go to the /ecommerce/control/policies page.
>>>
>>> I guess we'll have to look into details a bit more on our side Tim.
>>>
>>> -David
>>>
>>>
>>> On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:
>>>
>>> > All, we've been using the content manager for many of our
>>> > applications over the past year.  Recently, I had a client come
>>> > back for some follow on work and when I went to deploy the app on
>>> > my dev server, I realized there was a problem with the lookup
>>> > service.  In hopes that this will be more clear - here's the full
>>> > scenario.
>>> >
>>> > In my Content Manager,
>>> >
>>> > 1. I create a top level piece of content called something like
>>> > WebSite Root with the following parameters:
>>> > -- Document
>>> > -- Content Name - WebSite Root
>>> >
>>> > 2. I then create a DataResource with the following parameters:
>>> > -- Type Id - Long Text
>>> > -- Locale - en_US
>>> > -- Resource Name - Home Body
>>> > -- MIME Type Id - text/html
>>> > -- is Public - Y
>>> > -- Fill out Electronic Text
>>> >
>>> > 3. I then create a Content Instance with the following parameters:
>>> > -- Document
>>> > -- Content Name - Home Body
>>> > -- Locale - en_US
>>> > -- MIME Type - text/html
>>> >
>>> > 4. Then I go to the WebSite Root Content Object and Add an
>>> > associated piece of content:
>>> > -- Content ID to - ID of Content Instance that is Home Body
>>> > -- Content Assoc Type Id - Sub Section
>>> > -- Map Key (Very Important - or at least it used to be) - Home  
>>> Body
>>> >
>>> > So, I also created a new decorator that had a decorator-section-
>>> > include called sidebar and one called body.  Here's my Screen file
>>> > that worked great as of August of this year:
>>> >
>>> >     <screen name="Home">
>>> >         <section>
>>> >             <actions>
>>> >                 <set field="leftbarScreenName" value="leftbar"/>
>>> >                 <set field="MainColumnStyle" value="center"/>
>>> >                 <set field="title-property" value="Home"/>
>>> >             </actions>
>>> >             <widgets>
>>> >                 <decorator-screen name="content-decorator"
>>> > location="${parameters.mainDecoratorLocation}">
>>> >                     <decorator-section name="sidebar">
>>> >                         <sub-content content-id="10001" assoc-
>>> > name="Home Sidebar" />
>>> >                     </decorator-section>
>>> >                     <decorator-section name="body">
>>> >                         <sub-content content-id="10001" assoc-
>>> > name="Home" />
>>> >                     </decorator-section>
>>> >                 </decorator-screen>
>>> >             </widgets>
>>> >         </section>
>>> >     </screen>
>>> >
>>> > The effect that I'm seeing now is that EVERY single page -
>>> > regardless of what is put in the assoc-name - always just shows  
>>> the
>>> > very first association.   It doesn't matter if you have one piece
>>> > associated or 50 - each entry on each page that uses this lookup
>>> > style always gets the same response.
>>> >
>>> > Has anyone committed anything that would potentially have changed
>>> > the behavior of this module?
>>> >
>>> > Cheers,
>>> > Tim
>>> > --
>>> > Tim Ruppert
>>> > HotWax Media
>>> > http://www.hotwaxmedia.com
>>> >
>>> > o:801.649.6594
>>> > f:801.649.6595
>>> >
>>> >
>>>
>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

Scott Gray
Ah ha, that points to the problem:
ModelScreenWidget.java
Line 948:             this.mapKey = new
FlexibleStringExpander(UtilFormatOut.checkNull(subContentElement.getAttribute("map-key"),
subContentElement.getAttribute("assoc-name")));
getAttribute never returns null, if the attribute is undefined it just
returns an empty string, so assoc-name can never be assigned to mapKey

Regards
Scott

Tim Ruppert wrote:

> All, this has been solved - and I was right in my assumptions - the
> attribute name "assoc-name" did change somewhere along the line to
> "map-key" - which makes more sense anyways.
>
> Thanks to anyone who dug in there and looked to see if they'd made any
> changes.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Jan 6, 2007, at 3:10 AM, David E Jones wrote:
>
>>
>> Al,
>>
>> I wouldn't worry about it. As mentioned in my later reply to this,
>> the problem appears to be something specific to this the custom use
>> of this as the demo/test stuff I threw into OFBiz seems to be working
>> fine (ie the updated policies page in ecommerce).
>>
>> -David
>>
>>
>> On Jan 6, 2007, at 3:08 AM, Al Byers wrote:
>>
>>> I think this will all come under the current tasks to clean up the
>>> content
>>> manager. I will be looking at it in the next day or so.
>>>
>>> -Al
>>>
>>> On 1/6/07, David E Jones <[hidden email]> wrote:
>>>>
>>>>
>>>> Okay, I just did a quick little test and based on this have multiple
>>>> sub-content elements on a single page appears to be working fine. The
>>>> changes to test this are in SVN rev 493431.
>>>>
>>>> To test it just update, run "ant run-install" to get the new data in,
>>>> and then go to the /ecommerce/control/policies page.
>>>>
>>>> I guess we'll have to look into details a bit more on our side Tim.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:
>>>>
>>>> > All, we've been using the content manager for many of our
>>>> > applications over the past year.  Recently, I had a client come
>>>> > back for some follow on work and when I went to deploy the app on
>>>> > my dev server, I realized there was a problem with the lookup
>>>> > service.  In hopes that this will be more clear - here's the full
>>>> > scenario.
>>>> >
>>>> > In my Content Manager,
>>>> >
>>>> > 1. I create a top level piece of content called something like
>>>> > WebSite Root with the following parameters:
>>>> > -- Document
>>>> > -- Content Name - WebSite Root
>>>> >
>>>> > 2. I then create a DataResource with the following parameters:
>>>> > -- Type Id - Long Text
>>>> > -- Locale - en_US
>>>> > -- Resource Name - Home Body
>>>> > -- MIME Type Id - text/html
>>>> > -- is Public - Y
>>>> > -- Fill out Electronic Text
>>>> >
>>>> > 3. I then create a Content Instance with the following parameters:
>>>> > -- Document
>>>> > -- Content Name - Home Body
>>>> > -- Locale - en_US
>>>> > -- MIME Type - text/html
>>>> >
>>>> > 4. Then I go to the WebSite Root Content Object and Add an
>>>> > associated piece of content:
>>>> > -- Content ID to - ID of Content Instance that is Home Body
>>>> > -- Content Assoc Type Id - Sub Section
>>>> > -- Map Key (Very Important - or at least it used to be) - Home Body
>>>> >
>>>> > So, I also created a new decorator that had a decorator-section-
>>>> > include called sidebar and one called body.  Here's my Screen file
>>>> > that worked great as of August of this year:
>>>> >
>>>> >     <screen name="Home">
>>>> >         <section>
>>>> >             <actions>
>>>> >                 <set field="leftbarScreenName" value="leftbar"/>
>>>> >                 <set field="MainColumnStyle" value="center"/>
>>>> >                 <set field="title-property" value="Home"/>
>>>> >             </actions>
>>>> >             <widgets>
>>>> >                 <decorator-screen name="content-decorator"
>>>> > location="${parameters.mainDecoratorLocation}">
>>>> >                     <decorator-section name="sidebar">
>>>> >                         <sub-content content-id="10001" assoc-
>>>> > name="Home Sidebar" />
>>>> >                     </decorator-section>
>>>> >                     <decorator-section name="body">
>>>> >                         <sub-content content-id="10001" assoc-
>>>> > name="Home" />
>>>> >                     </decorator-section>
>>>> >                 </decorator-screen>
>>>> >             </widgets>
>>>> >         </section>
>>>> >     </screen>
>>>> >
>>>> > The effect that I'm seeing now is that EVERY single page -
>>>> > regardless of what is put in the assoc-name - always just shows the
>>>> > very first association.   It doesn't matter if you have one piece
>>>> > associated or 50 - each entry on each page that uses this lookup
>>>> > style always gets the same response.
>>>> >
>>>> > Has anyone committed anything that would potentially have changed
>>>> > the behavior of this module?
>>>> >
>>>> > Cheers,
>>>> > Tim
>>>> > --
>>>> > Tim Ruppert
>>>> > HotWax Media
>>>> > http://www.hotwaxmedia.com
>>>> >
>>>> > o:801.649.6594
>>>> > f:801.649.6595
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with the sub-content tag in Screen Definitions

David E Jones-2

Scott,

Nice, thanks for tracing that down, and thanks to Tim for reporting  
this. So the backwards compatibility code was messed up. Changing  
this from "checkNull" to "checkEmpty" should fix this, but in rev  
493653 I made a more explicit fix.

So, yes, "map-key" should be used for this attribute, but "assoc-
name" should now also be accepted.

-David


On Jan 6, 2007, at 7:04 PM, Scott Gray wrote:

> Ah ha, that points to the problem:
> ModelScreenWidget.java
> Line 948:             this.mapKey = new FlexibleStringExpander
> (UtilFormatOut.checkNull(subContentElement.getAttribute("map-key"),  
> subContentElement.getAttribute("assoc-name")));
> getAttribute never returns null, if the attribute is undefined it  
> just returns an empty string, so assoc-name can never be assigned  
> to mapKey
>
> Regards
> Scott
>
> Tim Ruppert wrote:
>> All, this has been solved - and I was right in my assumptions -  
>> the attribute name "assoc-name" did change somewhere along the  
>> line to "map-key" - which makes more sense anyways.
>>
>> Thanks to anyone who dug in there and looked to see if they'd made  
>> any changes.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>> On Jan 6, 2007, at 3:10 AM, David E Jones wrote:
>>
>>>
>>> Al,
>>>
>>> I wouldn't worry about it. As mentioned in my later reply to  
>>> this, the problem appears to be something specific to this the  
>>> custom use of this as the demo/test stuff I threw into OFBiz  
>>> seems to be working fine (ie the updated policies page in  
>>> ecommerce).
>>>
>>> -David
>>>
>>>
>>> On Jan 6, 2007, at 3:08 AM, Al Byers wrote:
>>>
>>>> I think this will all come under the current tasks to clean up  
>>>> the content
>>>> manager. I will be looking at it in the next day or so.
>>>>
>>>> -Al
>>>>
>>>> On 1/6/07, David E Jones <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Okay, I just did a quick little test and based on this have  
>>>>> multiple
>>>>> sub-content elements on a single page appears to be working  
>>>>> fine. The
>>>>> changes to test this are in SVN rev 493431.
>>>>>
>>>>> To test it just update, run "ant run-install" to get the new  
>>>>> data in,
>>>>> and then go to the /ecommerce/control/policies page.
>>>>>
>>>>> I guess we'll have to look into details a bit more on our side  
>>>>> Tim.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 5, 2007, at 9:14 PM, Tim Ruppert wrote:
>>>>>
>>>>> > All, we've been using the content manager for many of our
>>>>> > applications over the past year.  Recently, I had a client come
>>>>> > back for some follow on work and when I went to deploy the  
>>>>> app on
>>>>> > my dev server, I realized there was a problem with the lookup
>>>>> > service.  In hopes that this will be more clear - here's the  
>>>>> full
>>>>> > scenario.
>>>>> >
>>>>> > In my Content Manager,
>>>>> >
>>>>> > 1. I create a top level piece of content called something like
>>>>> > WebSite Root with the following parameters:
>>>>> > -- Document
>>>>> > -- Content Name - WebSite Root
>>>>> >
>>>>> > 2. I then create a DataResource with the following parameters:
>>>>> > -- Type Id - Long Text
>>>>> > -- Locale - en_US
>>>>> > -- Resource Name - Home Body
>>>>> > -- MIME Type Id - text/html
>>>>> > -- is Public - Y
>>>>> > -- Fill out Electronic Text
>>>>> >
>>>>> > 3. I then create a Content Instance with the following  
>>>>> parameters:
>>>>> > -- Document
>>>>> > -- Content Name - Home Body
>>>>> > -- Locale - en_US
>>>>> > -- MIME Type - text/html
>>>>> >
>>>>> > 4. Then I go to the WebSite Root Content Object and Add an
>>>>> > associated piece of content:
>>>>> > -- Content ID to - ID of Content Instance that is Home Body
>>>>> > -- Content Assoc Type Id - Sub Section
>>>>> > -- Map Key (Very Important - or at least it used to be) -  
>>>>> Home Body
>>>>> >
>>>>> > So, I also created a new decorator that had a decorator-section-
>>>>> > include called sidebar and one called body.  Here's my Screen  
>>>>> file
>>>>> > that worked great as of August of this year:
>>>>> >
>>>>> >     <screen name="Home">
>>>>> >         <section>
>>>>> >             <actions>
>>>>> >                 <set field="leftbarScreenName" value="leftbar"/>
>>>>> >                 <set field="MainColumnStyle" value="center"/>
>>>>> >                 <set field="title-property" value="Home"/>
>>>>> >             </actions>
>>>>> >             <widgets>
>>>>> >                 <decorator-screen name="content-decorator"
>>>>> > location="${parameters.mainDecoratorLocation}">
>>>>> >                     <decorator-section name="sidebar">
>>>>> >                         <sub-content content-id="10001" assoc-
>>>>> > name="Home Sidebar" />
>>>>> >                     </decorator-section>
>>>>> >                     <decorator-section name="body">
>>>>> >                         <sub-content content-id="10001" assoc-
>>>>> > name="Home" />
>>>>> >                     </decorator-section>
>>>>> >                 </decorator-screen>
>>>>> >             </widgets>
>>>>> >         </section>
>>>>> >     </screen>
>>>>> >
>>>>> > The effect that I'm seeing now is that EVERY single page -
>>>>> > regardless of what is put in the assoc-name - always just  
>>>>> shows the
>>>>> > very first association.   It doesn't matter if you have one  
>>>>> piece
>>>>> > associated or 50 - each entry on each page that uses this lookup
>>>>> > style always gets the same response.
>>>>> >
>>>>> > Has anyone committed anything that would potentially have  
>>>>> changed
>>>>> > the behavior of this module?
>>>>> >
>>>>> > Cheers,
>>>>> > Tim
>>>>> > --
>>>>> > Tim Ruppert
>>>>> > HotWax Media
>>>>> > http://www.hotwaxmedia.com
>>>>> >
>>>>> > o:801.649.6594
>>>>> > f:801.649.6595
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>


smime.p7s (3K) Download Attachment