RejectedSoftware Forums

Sign up

Pages: 1 2

Diet-ng

I just included the diet-ng as a dependency in my project and it will no longer build. I used html2jade previously to check my template syntax and was able to solve problems fairly quickly.
Using diet-ng produces some errors that I can not begin to figure out. I have included an example line from my template that worked without diet-ng:

input#form_instructions(type = 'hidden',name = 'form_instruction',value  = 'update') 

This produces the following error output:

../../../.dub/packages/diet-ng-1.1.1/diet-ng/source/diet/defs.d(34,3): Error: "useredit.dt(15): Singular HTML element 'input' may not have contents."

followed by another error

../../../.dub/packages/vibe-d-0.7.30/vibe-d/source/vibe/http/server.d(213,3): Error: template instance app.TMapp.getEditUser.render!("useredit.dt", _error, theUser, state, customerLink, allcountries, allRoles, allAlertFilters, allEventFilters, allClients, ud, legend, perms).render!("app", "app.TMapp.getEditUser").render.compileHTMLDietFile!("useredit.dt", req, _error, theUser, state, customerLink, allcountries, allRoles, allAlertFilters, allEventFilters, allClients, ud, legend, perms, DefaultFilters) error instantiating

Other than these two errors it would seem with a little work (pretty output) I could make the leap. Any help in pointing out the error of my ways or similar support tools like html2jade would be very much appreciated.

Thanks

Re: Diet-ng

On Tue, 24 Jan 2017 14:33:10 GMT, John More wrote:

I just included the diet-ng as a dependency in my project and it will no longer build. I used html2jade previously to check my template syntax and was able to solve problems fairly quickly.
Using diet-ng produces some errors that I can not begin to figure out. I have included an example line from my template that worked without diet-ng:

input#form_instructions(type = 'hidden',name = 'form_instruction',value  = 'update') 

This produces the following error output:

../../../.dub/packages/diet-ng-1.1.1/diet-ng/source/diet/defs.d(34,3): Error: "useredit.dt(15): Singular HTML element 'input' may not have contents."

It seems like the input tag has sone text contents or child elements, but the HTML standard prohibits any contents (it's just <input ... /> without a separate closing tag).

Re: Diet-ng

On Tue, 24 Jan 2017 21:22:30 GMT, Sönke Ludwig wrote:

It seems like the input tag has sone text contents or child elements, but the HTML standard prohibits any contents (it's just <input ... /> without a separate closing tag).

Having similar trouble, usually easily fixed because technically they are HTML errors tolerated by the earlier implementation of diet templates. However, there are now some odd interactions with white space, interspersed D code and template inheritance.

In all of the cases below, the template code was functioning and producing the HTML I expected in detail before I moved the project to diet-ng.

1.
I had a link tag in the head of a top level template used to inherit from, followed by a block declaration.

        link(rel="icon", type="image/png", href="images/favicon.png")
        block header

The compiler complained that the link tag had contents when this file was compiled. A blank line between the two solved this problem. There was no inappropriate extra indentation in any f the files inheriting from this so substituted tags should have been at the same nesting level not nominally inside the link tag.

2.
I had an input tag that was the last line in a file that inherited from the above, and that tag was at the end of code that replaced block content that was the very last line therein. So the input tag would nominally be placed last in HTML output followed by no visible text.

The compiler complained that the input tag had contents. Both the top level template and the inheriting file had a newline at the end of their last visible lines, but no characters followed either of those newlines. When I removed the newline from the end of the input tag definition at the end of the inheriting file, the problem went away.

3.
I had one of two input tags being produce by if all inside a div tag, which in turn was followed by another div tag, i.e. one at the same level as the div tag containing the branch.

The compiler complained that the input tag had contents. Placing a blank line after the last input tag in the branch before the next div fixed the problem.

All these troubles look like bugs to me. Am I mistaken?

Re: Diet-ng

On Sun, 12 Feb 2017 18:59:41 GMT, Carl Sturtivant wrote:

On Tue, 24 Jan 2017 21:22:30 GMT, Sönke Ludwig wrote:

It seems like the input tag has sone text contents or child elements, but the HTML standard prohibits any contents (it's just <input ... /> without a separate closing tag).

Having similar trouble, usually easily fixed because technically they are HTML errors tolerated by the earlier implementation of diet templates. However, there are now some odd interactions with white space, interspersed D code and template inheritance.

In all of the cases below, the template code was functioning and producing the HTML I expected in detail before I moved the project to diet-ng.

1.
I had a link tag in the head of a top level template used to inherit from, followed by a block declaration.

        link(rel="icon", type="image/png", href="images/favicon.png")
        block header

The compiler complained that the link tag had contents when this file was compiled. A blank line between the two solved this problem. There was no inappropriate extra indentation in any f the files inheriting from this so substituted tags should have been at the same nesting level not nominally inside the link tag.

2.
I had an input tag that was the last line in a file that inherited from the above, and that tag was at the end of code that replaced block content that was the very last line therein. So the input tag would nominally be placed last in HTML output followed by no visible text.

The compiler complained that the input tag had contents. Both the top level template and the inheriting file had a newline at the end of their last visible lines, but no characters followed either of those newlines. When I removed the newline from the end of the input tag definition at the end of the inheriting file, the problem went away.

The snippet from the other thread contains such combinations, but doesn't trigger the error. Could there be something else that was specific for this issue? http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/40831

3.
I had one of two input tags being produce by if all inside a div tag, which in turn was followed by another div tag, i.e. one at the same level as the div tag containing the branch.

The compiler complained that the input tag had contents. Placing a blank line after the last input tag in the branch before the next div fixed the problem.

All these troubles look like bugs to me. Am I mistaken?

Definitely sounds like bugs. Could it be that there were some strange newlines in the file, or some special Unicode characters? I have not been able reproduce any of the issues from the description so far. This is what I used for number three:

div
	- if (true)
		input
	div

Re: Diet-ng

On Wed, 15 Feb 2017 14:25:15 GMT, Sönke Ludwig wrote:

2.
I had an input tag that was the last line in a file that inherited from the above, and that tag was at the end of code that replaced block content that was the very last line therein. So the input tag would nominally be placed last in HTML output followed by no visible text.

The compiler complained that the input tag had contents. Both the top level template and the inheriting file had a newline at the end of their last visible lines, but no characters followed either of those newlines. When I removed the newline from the end of the input tag definition at the end of the inheriting file, the problem went away.

The snippet from the other thread contains such combinations, but doesn't trigger the error. Could there be something else that was specific for this issue? http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/40831

I noticed that too. I've had trouble isolating these behaviors into small examples. Still investigating.

Definitely sounds like bugs. Could it be that there were some strange newlines in the file, or some special Unicode characters? I have not been able reproduce any of the issues from the description so far. This is what I used for number three:

div
	- if (true)
		input
	div


My example had the second div indented out to the level of the first div, and had an else branch to the if.

I'll look into exactly what in the file is invisible, and continue to look into isolating these behaviors into small examples. I'll respond to this post when I can.

Re: Diet-ng

On Sun, 12 Feb 2017 18:59:41 GMT, Carl Sturtivant wrote:

1.
I had a link tag in the head of a top level template used to inherit from, followed by a block declaration.

        link(rel="icon", type="image/png", href="images/favicon.png")
        block header

The compiler complained that the link tag had contents when this file was compiled. A blank line between the two solved this problem. There was no inappropriate extra indentation in any f the files inheriting from this so substituted tags should have been at the same nesting level not nominally inside the link tag.

A look at the white space in this file showed that there were two trailing spaces at the end of the link line. When I removed just one of them, the project compiled just fine.

Re: Diet-ng

On Wed, 15 Feb 2017 14:25:15 GMT, Sönke Ludwig wrote:

Definitely sounds like bugs. Could it be that there were some strange newlines in the file, or some special Unicode characters? I have not been able reproduce any of the issues from the description so far.

Removing the two spaces from the end of the link line (in the diet file inherited from) eliminated the other two errors. When I tried to investigate further with the blank line following the link line in place to eliminate all but the other errors I mentioned numbered 2, 3, I did not get the same behavior, because (perhaps) it depends upon how much white space is on that blank line. In fact I was only able to get more errors after that.

In any case, the entire cascade of errors stemmed from having two spaces at the end of a line defining a link tag followed by a block declaration at the same level of indentation. (See my previous post about fixing that one problem, the one I numbered 1.) It turned out that introducing a blank line between the two was only a partial fix of the root cause. While it fixed the problem of the compiler complaining about the link tag, did not fix problems induced in files that inherited from this, whereas the reduction of the number of spaces to one or zero after the link tag definition fixed everything.

Re: Diet-ng

Am 18.02.2017 um 20:58 schrieb Carl Sturtivant:

On Sun, 12 Feb 2017 18:59:41 GMT, Carl Sturtivant wrote:

1.
I had a link tag in the head of a top level template used to inherit from, followed by a block declaration.

        link(rel="icon", type="image/png", href="images/favicon.png")
        block header

The compiler complained that the link tag had contents when this file was compiled. A blank line between the two solved this problem. There was no inappropriate extra indentation in any f the files inheriting from this so substituted tags should have been at the same nesting level not nominally inside the link tag.

A look at the white space in this file showed that there were two trailing spaces at the end of the link line. When I removed just one of them, the project compiled just fine.

Okay, that makes sense in a way, because the second space will be
treated as text content. But the check in this case obviously could
simply ignore white space. I'll add that.

Re: Diet-ng

On Sun, 19 Feb 2017 22:21:11 +0100, Sönke Ludwig wrote:

Am 18.02.2017 um 20:58 schrieb Carl Sturtivant:

On Sun, 12 Feb 2017 18:59:41 GMT, Carl Sturtivant wrote:

1.
I had a link tag in the head of a top level template used to inherit from, followed by a block declaration.

        link(rel="icon", type="image/png", href="images/favicon.png")
        block header

The compiler complained that the link tag had contents when this file was compiled. A blank line between the two solved this problem. There was no inappropriate extra indentation in any f the files inheriting from this so substituted tags should have been at the same nesting level not nominally inside the link tag.

A look at the white space in this file showed that there were two trailing spaces at the end of the link line. When I removed just one of them, the project compiled just fine.

Okay, that makes sense in a way, because the second space will be
treated as text content. But the check in this case obviously could
simply ignore white space. I'll add that.

75b52b4

Re: Diet-ng

On Sat, 18 Feb 2017 20:34:11 GMT, Carl Sturtivant wrote:

On Wed, 15 Feb 2017 14:25:15 GMT, Sönke Ludwig wrote:

Definitely sounds like bugs. Could it be that there were some strange newlines in the file, or some special Unicode characters? I have not been able reproduce any of the issues from the description so far.

Removing the two spaces from the end of the link line (in the diet file inherited from) eliminated the other two errors. When I tried to investigate further with the blank line following the link line in place to eliminate all but the other errors I mentioned numbered 2, 3, I did not get the same behavior, because (perhaps) it depends upon how much white space is on that blank line. In fact I was only able to get more errors after that.

In any case, the entire cascade of errors stemmed from having two spaces at the end of a line defining a link tag followed by a block declaration at the same level of indentation. (See my previous post about fixing that one problem, the one I numbered 1.) It turned out that introducing a blank line between the two was only a partial fix of the root cause. While it fixed the problem of the compiler complaining about the link tag, did not fix problems induced in files that inherited from this, whereas the reduction of the number of spaces to one or zero after the link tag definition fixed everything.

It looks like the fix above should also have fixed these cases, although I'm not sure about what really happened in the inheritance case.

Pages: 1 2