Issue with the sub-content tag in Screen Definitions
Locked
Issue with the sub-content tag in Screen Definitions
 
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
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)
Re: Issue with the sub-content tag in Screen Definitions
|
|
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 > > |
Re: Issue with the sub-content tag in Screen Definitions
|
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
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 >> > >> > >> >> >> >> |
Re: Issue with the sub-content tag in Screen Definitions
|
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
Re: Issue with the sub-content tag in Screen Definitions
|
|
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 >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> >>> >> >> > |
| Free forum by Nabble | Edit this page |