Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another nested object problem #59

Open
dougalcampbell opened this issue Apr 12, 2012 · 3 comments
Open

Another nested object problem #59

dougalcampbell opened this issue Apr 12, 2012 · 3 comments

Comments

@dougalcampbell
Copy link

When dealing with a nested object, plates seems to lose track of something if the template uses higher-level data after dealing with the sub-object. I've created a test case, and a gist to illustrate: https://gist.github.com/2370943

As you'll see, plates seems to be outputting the unprocessed template snippet, then the copy with substitutions made.

dougalcampbell added a commit to dougalcampbell/plates that referenced this issue Apr 12, 2012
@dougalcampbell
Copy link
Author

Okay, I've tinkered with this off and on, and tracked down the source of the problem.

At the beginning of the iterate() method, plates uses a naive way of balancing out the tags for the current block being mapped to a data object. It uses String.lastIndexOf() without regard to whether unrelated html might exist at the end of the current segment.

When there is additional template text after where the current block should end (a common use-case -- think about footers after a data block), and the tagnames between the current block and the appended block match, this will grab too much text. For example. consider this template:

<div id='article'>
  <div class='byline'></div>
  <div class='content'></div>
</div>
<div id='footer'></div>

I've created a new gist (simpler than my previous one) to illustrate: https://gist.github.com/2595351

If plates was handling things as a DOM (even just a simplified one), it would be easier to handle. You could just count elements on the stack. But since it's doing pseudo-stream state-machine parsing, it's tricker to look ahead. I'm mulling it over to see if I can come up with a patch that's not too ugly.

@dougalcampbell
Copy link
Author

I've got a patch that seems to be working, though I haven't done extensive testing yet. One known flaw so far, is with dealing with html comments (or presumably other content) at the end of a sub-block being processed.

dougalcampbell@36223d5

@dougalcampbell
Copy link
Author

Okay, my latest fix seems to work pretty well. The only niggle I have is that it doesn't perfectly preserve whitespace after processing a sub-object block for some reason. But none of the other test cases worry about whitespace, so I guess I won't either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant