way to know whether my binding is for a conditional or not?

[Mark Anderson]

Suppose i want to enforce a stringent rule that interpolated content can't be null or empty string,

but it is ok if the binding is only to be used in a conditional like {{#likes_cheezburger}}.

Is there some way to distinguish those two circumstances in an ObjectHandler, i guess using

the TemplateContext that is passed in?

Thanks.

-mda

[Sam]

You can just override ObjectHandler.stringify() to fail when the the object is null or "". It is called to ultimately convert any values to strings.

Sam 

[Mark D. Anderson]

but stringify() is just giving me the Object, i don't know what the name or expression is.

--

You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

[Mark D. Anderson]

also, it would seem that null enforcement is already done before stringify() is called,

because since the default implementation does object.toString(),

clearly object can't be null.

 

-mda

[Sam Pullara]

You're right. You may have to do it all the way up in ValueCode. You want to selectively prevent some variables from being null/"" when evaluated as values? Or is there more to it?

Sam

--
You received this message because you are subscribed to the Google Groups "mustache.java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mustachejava...@googlegroups.com.

[Mark D. Anderson]

That is about it. My goal is something like this:
- Fatal error for a reference to a variable with no binding at all (can be accomplished with my getWrapper override)
- Ok to reference a null or empty string value in a conditional like {{#has_cheezburger}}
- Log an error with details (but not throw) if a null or empty string is interpolated.

btw, it would be nice if the messy StringBuilder stuff in GuardedBinding.getWrapper were available
as a separate utility like
String makeWarning(Wrapper wrapper, String name, Object[] scopes)
and also if the actual issuance of the warning were wrapped in another overridable method like
logWarning(String warning)

-mda

On Mon, Apr 4, 2016, at 05:39 PM, Sam Pullara wrote:
> You're right. You may have to do it all the way up in ValueCode. You want to selectively prevent some variables from being null/"" when evaluated as values? Or is there more to it?
>
> Sam
>
> On Mon, Apr 4, 2016 at 5:26 PM, Mark D. Anderson <m...@discerning.com> wrote:

>> __

[Sam]

After building this extension, I think it would be nice if I had a couple callbacks for checking the values. However, I think you can do what you want like I have in this test:

https://github.com/spullara/mustache.java/blob/master/compiler/src/test/java/com/github/mustachejava/InterpreterTest.java#L1301

Sam

>>>> To unsubscribe from this group and all its topics, send an email to mustachejava+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>  
>>>


>>> --
>>> You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

>>> To unsubscribe from this group and all its topics, send an email to mustachejava+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>  
>>


>> --
>>  You received this message because you are subscribed to the Google Groups "mustache.java" group.

>>  To unsubscribe from this group and stop receiving emails from it, send an email to mustachejava+unsubscribe@googlegroups.com.

>>  For more options, visit https://groups.google.com/d/optout.
>
>


> --
>  You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.
>  To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

>  To unsubscribe from this group and all its topics, send an email to mustachejava+unsubscribe@googlegroups.com.

[Mark D. Anderson]

How does the ObjectHandler.createBinding and later Wrapper.getWrapper call relate to a call to MustacheVisitor.value ?

There are so many hook points I'm a bit lost regarding overall flow....

 

-mda

To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

[Sam]

I should probably write something up on the internals and put it on the wiki. At a high level:

During compilation the MustacheParser makes callbacks into the MustacheVisitor to construct a graph of Nodes representing parts of the template. Each Node that extracts a value creates a Binding object — when using the default ReflectionObjectHandler that is a GuardedBinding. When you execute a template, it executes the graph of Nodes starting at the root. When you encounter a variable, the Binding is called with the current set of scopes. Each GuardedBinding tracks a set of Wrappers — if this is the first call or none of the wrappers successfully match the scopes, a new Wrapper is created that includes all the guards necessary to ensure that it is only used when the scopes are the same shape.

The design of the system is very much like the design of JITs and other runtime optimizing compilers and works optimally when you compile once and execute many times.

Any other questions? 

Sam

[Mark D. Anderson]

How does compilation work (or provide any benefit) when partial resolving is done dynamically -- for example

in the internationalization case.

For example, we have a scope value of "lang", and based on that, we will attempt to resolve a partial "X" as "X.spa" or whatever

the value of "lang" is.

I think you are doing something similar in your test code for localization.

 

In terms of analogies, i can see some benefit to caching parse trees after resolution, but at least for us, an upfront compile

without any scopes isn't going to get us much.

 

Unless I'm still misunderstanding the whole design.

 

-mda

To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

[Sam Pullara]

When partials are resolved dynamically they are compiled as they are encountered. There is an advantage / benefit as you would normally then not recompile when the same partial is encountered again. The biggest advantage compilation gets you is that there is no memory allocation done by mustache.java during execution and you don't spend the effort parsing, etc.

Since compilation is fast (but not as fast as not doing it) you may be able to get away with recompiling every time and use SimpleObjectHandler that doesn't bother doing any binding caching / guarding since you would only be executing once per compile. It really depends on how sensitive you are to latency / performance.

Sam

>>>> To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.

>>>

>>>

 

 

>>> --

>>> You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.

>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

>>> To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.

>>

>>

 

 

>> --

>>  You received this message because you are subscribed to the Google Groups "mustache.java" group.

>>  To unsubscribe from this group and stop receiving emails from it, send an email to mustachejava...@googlegroups.com.

>>  For more options, visit https://groups.google.com/d/optout.

>

>

 

 

> --

>  You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.

>  To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

>  To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

>  For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "mustache.java" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/mustachejava/vyVEZd7c5mw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to mustachejava...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "mustache.java" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mustachejava...@googlegroups.com.