Let us now delve deeper into the concept of design templates so you can realize all of the value that RealtZapp brings you.
Sometimes it is necessary to use HTML comment elements to wrap around the templating code something like this...
<!-- {{#with @root.agent}} --> ... <!-- {{/with}} -->
In RZ Designer this method is employed in many of the built-in bloks. e.g. Agent block. Additionally. we provide you with several ways to sneak in the templating code...
Some data fields contain embedded HTML code e.g. listing's blockAddress field. These must be wrapped in {{{ ... }}} instead of the normal {{ ... }}. So, in the case of blockAddress it looks like {{{blockAddress}}}.
The listing's Bullets field is an example of a more complex use of the templating code. It looks like...
{#each bullets}} {{this}} {{/each}}
The above code is a each repeater and {{this}} is just a way of designating the value of of whatever is being iterated.
We said you can use the templating code in settings and styles like a color or background color style e.g.{{@root.agent.Color1.Html}}.
If you are developing templates for yourself or your firm's agent's then you may not want to go as far as using templating codes for colors and other brand aspects since everyone in the firm has the same brand. However, if you are creating a design template to be published in the Gallery then templating as much as possible is good.
Color data uses a special syntax. That is because a Color contains multiple properties for use in many ways. Here is what a Color looks like...
A well designed template layout will flow and be responsive yet will not overflow or cutoff. The variability of the data Data length, missing or not, applicability, etc. all require consideration. Let us use listings as an example going forward.
The listing About field can be short or really long. So, you have to control the height and width and overflow of certain elements like the About.
What about missing/empty data? Well missing data just does not show up so its space usually collapses and disappears.
Certain fields are applicable to one type of property but not others i.e. commercial vs residential or industrial vs office. A design template an work for any/all cases thanks to some templating features.
You already know the templating syntax includes things like {{#with ...}} and {{#each ...}} but it also includes some other logical features...
{{#if ...}} ... {{else}} ... {{/if}}
{{#unless ... }} ... {{else}} ... {{/unless}} - opposite of #if
For example...
{{#if Sale}} For Sale {{else}} Not For Sale {{/if}}
These are truthy meaning true/false. Fields like Sale and/or Lease are indeed either true or fase but what about ListingType, it is not true/false, it is either 'Commercial' or 'Residential'. Well, we have thrown in an extra ditty to help you...
is.[listing type | property type | property subtype]
We use is.[...] because is.Multi-Family does not work but is.[Multi-Family] does work. At present, only ListingType, PropertyType, and PropertySubType value are supported.
In conclusion, the above templating syntax can be used to create design templates that accommodate different types of properties. One last example...
{{#if is.Commercial}}
{{GrossBldg}} sqft
RBA: {{RBA}}
{{/if}}
{{#if is.Residential}}
{{Heated}} sqft
Beds: {{Bedrooms}
Baths: {{Bathrooms}}
{{/if}}
The handlebars templating framework has more features so if you are interested, visit handlebarsjs.com.