Added support for multiple fragments definition #166
Conversation
Created different processor names for source and target elements: define and collect
|
Hi @Vineg, thanks for the PR! Firstly though, could you explain to me what a "collect processor" is for? I'd like to understand the use case and reasoning behind the processor so I can determine where it fits into the overall layout dialect. I can gather a few details from what you've written in this PR and in your code, but it'd help me to see/read it explained to me too. |
|
My use case is simple. I have popups in the end of the Common.html body template. Then I define some popups in Layout.html and some more in Content.html. I want them all to appear in the end. I probably could do this with current "fragment" processor, but it would be quite inconvenient Another use case would be collecting head contents among children, but you already implemented it explicitly |
|
@ultraq just added one more test case we really missing in our project |
|
Sorry for taking so long on getting back to you with this PR! (I've been on holiday.) I especially like what you've done with accumulating the fragments, and I've been thinking about turning that into the standard behaviour for how fragments are found. But then when it comes to deciding which fragments to use, maybe make it configurable by the dev to either take the first with the same name (current behaviour of Anyway, that's just an idea I have and probably won't implement for a long time. Until then I'll merge this PR and create a 2.3.0-SNAPSHOT release with this included in it. I'll get around to writing some docs for it too once I can see how to fit it in with the other stuff. If you'd like to be added to the TODO:
|
I've separated processor names to avoid ambiguity for cases with nesting. To retain backward compatibility I left "fragment" processor and created separate "define" and "collect" processors.