You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Tim Ruppert <ti...@hotwaxmedia.com> on 2007/01/06 05:14:33 UTC
Issue with the sub-content tag in Screen Definitions
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
Re: Issue with the sub-content tag in Screen Definitions
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <jo...@undersunconsulting.com> 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by Scott Gray <le...@gmail.com>.
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 <jo...@undersunconsulting.com> 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
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>
>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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 <jo...@undersunconsulting.com> 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
>>> >
>>> >
>>>
>>>
>>>
>>>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <jo...@undersunconsulting.com> 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
>> >
>> >
>>
>>
>>
>>
Re: Issue with the sub-content tag in Screen Definitions
Posted by Al Byers <by...@automationgroups.com>.
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 <jo...@undersunconsulting.com> 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
> >
> >
>
>
>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>>>
>>>
>>>
>>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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
>>
>>
>>
>
Re: Issue with the sub-content tag in Screen Definitions
Posted by Scott Gray <le...@gmail.com>.
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
>
>
>