[stringtemplate-interest] FW: FW: The select-option problem

[Koerner, Ron]

>> so I understand that stringtemplate should not access the business
>> model, but needs a separate code layer which turns the business model
>> into a specialized view model, which is then modified another time by
>> the template engine (formatters, removing null elements) to be
finally
>> used to generate output.
>
> Assuming the complexity of requirements that it seems you happen to
need
> for your system, then this might be a suitable approach to achieving
> your requirements. It's a decision for you of course.

I think this is a generalization which is always valid, even if
sometimes certain elements are a litte degenerated.

>> The view model and the view itself are highly coupled and if you
change
>
> Good design principle is to minimize coupling. If you mean by "the
view
> itself", your ST templates, then there is still no reason to not
> minimize coupling. At least to the extent you can.

This is exactly my intention.

>> On the other hand that means things like custom formatters and
>> null-element-removal are actually violating this because they are
>> putting logic into the template which actually belongs into the view
>
> Yes, from the perspective of view view (templates) and view
controller/
> model, this is the case.
>
> The question that has been and is still with the ST community, is what
> can be included in ST 'code', whilst still strongly encouraging view
and
> model separation.

Here we are speaking of business model and view view?

>> model generator. I'm sure there are more things. So why can't we have
>> another thing which would be 100% pure functional and would not need
>> us to revert to code which looks like a dirty hack.
>
> No reason at all. I am personally an advocate for a goodly and full
> functional grammar for ST.

I meant functional in the sense of "no side effects". I assume we are
agreeing very strongly on this point.

> It will be a great benefit if you now make your enhancement proposal
> in a clear and concise way, which is as suitable for a specification
> document as you can achieve. You have joined the ST community at a
> rather auspicious time...

It will be too late for my current problem (which I have solved in
several ways now, some purely within templates), but I'd like to
contribute.

> Here's a thought: does it make sense to have two templating layers -
the
> low level 'pure ST declarative/ combinatorial templates' and a higher
> view-controller/ view-model layer, which is a functional expression
> language tailored specifically for views.

This is something I was wondering about when I went to sleep.

I think we have the following components in about every system, even if
these sometimes collapse or are implicit:

- business model
- page model builder
- page model
- render builder
- render specification
- render model
- renderer

The business model comprises all the data and entities reflecting the
universe of the program. A displayed page will contain some data out
of this universe, either raw or processed. This data is the page
model, which is built by the page model builder. The page model only
contains data that should be displayed, but does not make any
assumptions on how it is displayed. Therefore it must not contain data
which is only used to satisfy something in the render pipeline.
Model-View separation happens between the page model and the render
builder.

The business model would for example contain some total and regional
sales numbers per month. The page model builder would copy or
reference that data and would add percentages per month and an average
per year and put that into the page model.

The render builder uses the page model and a render specification to
build the render model, which is interpreted by the renderer to
produce output.

The render model is more like a scene graph, i.e. it contains simply
all of the elements which are displayed later. The renderer is a fixed
piece of code, i.e. it will not be configured or parametrized. At
least not on a page-by-page base. The easiest forms of render model
and renderer are a list of strings and a piece of code concatenating
these strings and output the result.

The render builder will only compute stuff related purely to
displaying the page model but may not provide additional data or
aggregate provided data.


In our case the page model builder is whoever generates a
StringTemplate and the page model is built by several calls to
st.setAttribute(). The render builder is the string template engine,
the render specification is the template. Render model and renderer
are also buried in the string template engine and not really visible
to the user.

Right now, almost all information only needed for rendering is already
contained in the render specification where it belongs. IMHO, there is
one exception: the render builder cannot identify an entity by name,
it can only select an entity by name.

There are a lot of cases which make it necessary to handle an element
of a list in a special way. Since it is not easily possible to
identify the special element by name the usual workaround is to enrich
the page model with a list containing all the elements paired with a
hint whether it is the special element or not. This clearly violates
model-view separation as explained above.

It is arguable whether the representation of the special element by
name (or by index) is arbitrary or natural (I think a single element
selection is naturally done by name or index) or a per-list-element
hint is arbitrary or natural. Anyway, it is fact that both cases occur
in real-world.

Examples are:
- select/option's and input/radio's HTML representation uses a
per-element-hint
- select/option's and input/radio's data model (i.e. form output) uses
an element-name
- GTK+ radio buttons use a per-element-hint
- GTK+ select box uses an element-name

If someone would build an application which outputs web interfaces and
GTK+ applications, it would not be easily possible to build templates
which would do both unless the page model contains both
representations of the selected element.

(I know it is not too complicated, albeit not good for performance, to
extract the name from a list containing names and hint pairs)

All that said, I'd like to place a feature request to the render
specification and render builder which allows to conditionally
evaluate a piece of text, if two string values, which may be constants
or evaluated templates, are equal. A negated form would fit in
naturally. This does not violate model-view separation but makes it
possible.

This could be implemented either by a function eq(x,y) which evaluates
to true if the evaluated forms of x and y are equal, by an infix
operator == or = or by a special conditional eq(x,y), which can be
used where ever if(x) is used.
Personally I tend to like the function eq(x,y) most. The only problem
with that is an inconsistent appearance with other multi-argument
"functions" i.e. templates, since these have only named parameters
whereas the eq-function would benefit from positional parameters.

I once built a protocol builder targeting multiple programming
languages with string template and found named parameters very unhandy
most of the time. Therefore I'd like to see positional parameters for
templates with more than one parameter.

Regards,
Ron

-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.