Re: [uportal-dev] dlm merging fragments

[Eric Dalquist]

So a few questions, points and ramblings.










-Eric




Timothy Carroll wrote:

Being able to define the header and footer via DLM fragments would be great, the further we get away from template users the better in my view. How this is done has some serious considerations though. Currently the DLM merge is only done once, at login, and that XML DOM is used for the rest of the user's session. The merge process is not cheap and we would very likely not want it done any more than once per session under most any circumstances, so we need to figure out a way to do this that doesn't require the merge to re-run. This could involve expanding on the header/footer sections of the layout tree to allow for headers & footers to be structured into 'tabs' as well that correspond with the main tabs or to just move the header/footer data into the tab node in the tree. The structure transform would need to be updated to put out the same content from this changed layout tree which shouldn't be too difficult. Keeping the output of the structure transform the same (header, tabs/columns/channels, footer) would require that the structure transform be re-run each time the tab is changed. Currently the only time the structure transform needs to be re-run is when the user's underlying layout changes. If MarkB happens to be lurking and catches this I'd love to hear a bit about the planned enhancements around having fragments that were different sizes than 'a tab' to see if we could get some inspiration on how to define the header & footer as/in fragments. I'm thinking what may be the desired solution that still gives us good caching options is to somehow add the ability to define header/footer fragments similar to how tab fragments are now defined. This would allow you to customize the header based on who is logged in though you do loose the ability to have a different header per-tab which would be there in your proposed solution. PS: sorry if that is a bit rambling, I'm reading through UserInstance right now to figure out all out before making the next set of changes for pluto 1.1

these folders appear to be filtered in FragmentActivator.java (fragmentizeLayout method). in fact, changing line 458/459:

from:

if ( ! folder.getAttribute( "type" ).equals( "regular" ) ||
      folder.getAttribute( "hidden" ).equals( "true" ) )

to:

if ( folder.getAttribute( "hidden" ).equals( "true" ) )



it would actually be cool to be able to configure this behavior.

1. dlm ignores header/footer
2. dlm merges header/footer from all fragments
3. dlm displays header/footer associated with the selected tab

thoughts anyone???

thanks, tim


Timothy Carroll wrote:

results in the header/footer of all fragments getting merged regardless of which tab is selected. someone with some real solid knowledge of the dlm rendering pipeline may be able to comment on the reprecussions of such a change. i don't know whether this is a better behavior or not, but it may warrant some discussion.

i found an interesting thing today...



has anyone else experienced this behavior?

thanks, tim

specifying content for the header and footer folders within a fragment seem to be ignored, so in order to have content in the header or footer, you have to specify it using a template user rather than a fragment. i was hoping to be able to have a completely empty template user and use dlm merged fragments (exclusively) for role based content.

smime.p7s
Description: S/MIME Cryptographic Signature