Scala template engine and "designer-friendliness"

[Manuel Bernhardt]

Hi all,

I've been working a bit with lift lately and next to cursing a lot
(because it for example "magically" changes IDs, form input names and
so on), there are a couple of things that are actually rather nice
over there.

One of them is the approach to templating which is very
designer-friendly in that you just write HTML and add things inline,
e.g.

<div id="someId" class="lift:doSomeMagicFoo">
<p>This is just some example markup that will disappear at
runtime and could be replaced by something entirely different.</p>
</div>

If I'm not mistaken this kind of inline way of doing things is also
used in Wicket and I've seen it used in other template engines
(Cambridge comes to my mind).

Additionally since lift is "DOM-based" it is also possible to add in
example markup that gets replaced at runtime by real DOM markup.

And this does come in handy when you for example have a designer that
can start off by preparing the general HTML layout, add in some
example content, and then developers come in afterwards and extend the
HTML templates in a non-intrusive way by adding these inline code
snippets.

Now I do realize that this is not the same approach to templating as
the play-scala templating engine.

My question is more along the lines of: what methods do you use in
order to keep the designers in your project happy with this kind of
template style? Are they generally fine with the inline syntax, how do
you deal with example markup, etc. ? Are there any nifty tricks
involving diff tools to have a HTML-only version for designers and a
"technical" version for developers?

Another mechanism that comes to my mind is to use e.g. knockoutJS
which does data-binding via HTML5-like "data-bind" attributes. Then
again, I'm not too sure how one would deal with example data there.

Any input on this topic would be welcome, I'm curious what approaches
exist for this.

Thanks,

Manuel

[Rakesh Waghela]

You have hit the right chord !

Play and many other frameworks lack designer friendly template system...
When use case is to develop wireframes first an then to do server side weaving.. things get a bit frustrating for a Web Designer...!

[Aaron White]

Agreed, strict HTML templating systems are the way to do for teams
working together IMHO

[Sadek Drobi]

I don't seem to understand, what stops u today in play from writing pure HTML templates for wireframes before filling in data?

To correctly direct the discussion, are you guys actual designers or just playing the role for the discussion sake?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/KeXys7J7xP8J.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Per Wiklander]

On Jun 28, 9:14 pm, Sadek Drobi <sadek.dr...@gmail.com> wrote:
> I don't seem to understand, what stops u today in play from writing pure
> HTML templates for wireframes before filling in data?
>
> To correctly direct the discussion, are you guys actual designers or just
> playing the role for the discussion sake?

It sounds like the designers previously mentioned here would have a
need to keep working on the HTML after the initial handoff to the
developers. Why would it otherwise be a problem? It's not like the
developers have any problem modifying the HTML to their needs, right?

[Manuel Bernhardt]

>> To correctly direct the discussion, are you guys actual designers or just
>> playing the role for the discussion sake?

I myself am not a designer. In a new project / team I am working, the
design part does play a key role and this is one of the main arguments
for going with lift. Being a developer who likes to be in control of
things (amongst which, how javascript gets executed, form controls
rendered etc.) I feel some kind pain with lift however, so I am trying
to see means to replicate some of that functionality / behavior with
Play.

>> I don't seem to understand, what stops u today in play from writing pure
>> HTML templates for wireframes before filling in data?

From the experience the guys I'm working with have, there's often a
need to add bits and pieces of design work when the project is already
well under way. With templating engines such as Freemarker this
becomes problematic for designers because it's kindof hard to find a
way in a jungle of expressions and loops (which you usually get when
the templates grow complicated).

So in essence, what I mean with "designer-friendly" is a system in
which the view code remains readable to folks that know mostly HTML
and CSS, but don't want to / need to get to know other constructs to
do their work.

One solution may be to work on improving a wireframe and have
developers port that to the real implementation. That being said, I
can easily imagine that the amount of effort required by this process
is directly proportional to the complexity and the amount of templates
involved. This is why I was asking about some kind of nifty diff tool
that would make that kind of work easier.

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

[Ivan Meredith]

This sounds pretty hard, do you know where lift documentation is on this is?

Wouldn't you need syntax to map your loops to the html for the diff?.

In my experience code that needs to be changed is usually the html and not most of the stuff that uses expressions anyway. 

[Julien Richard-Foy]

For my part, designers I’m working with write the markup themselves,
directly using the Play! template engine. The syntax is pretty easy to
learn.

[Rakesh Waghela]

Cambridge Template author has explained this pain in his goals..

http://code.google.com/p/cambridge/wiki/TemplateAuthorsGuide#What_is_Cambridge?

What is Cambridge?

Cambridge is a Template Engine for generating Markup Languages. It can be used to render web (html) pages or to generate xml documents or even for generating plain text with dynamic data in it. It can be used as an alternative to other Templating solutions for Java like JSP, Freemarker or Velocity.

What makes Cambridge different than other template engines?

• The template files are pure html documents. You can edit them using any authoring tool or open them in your browser and it will be rendered correctly.
• Less cluttered. You don't need to add any external tags or scripts into your template files. Cambridge knows the dom structure of your document and uses the scopes of your existing tags to identify where a dynamic behavior will be effective. (This doesn't mean that the templates have to be valid XML documents.) All you need to do as a developer is to add attributes to your existing tags.
• Cambridge is highly extensible. You can write your own behaviors, functions, tags. You can select from a list of different expression languages to use.
• Supports Template inheritance. Cambridge templates can extend other templates to override some tags that are defined in parent templates. This is much more convenient than just using includes which are also supported.
• Provides a DOM like Java API to modify tag structure of the templates. This way you can convert a completely static html file into a dynamic template using the Java API.
• Supports popular web frameworks. You can use Cambridge with Servlets, JaxRS (Jersey, RestEasy), Spring MVC, Struts 2 and Play Framework.

[Ivan Meredith]

Then the answer is probably just use cambridge?

I personally don't like the way cambridge does things, but hey, play has 4 (maybe more?) great templating options so just pick the one that suits your work flow. There is definitely not one 'right' way of doing things.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/kHqc3IjmFUMJ.

[GrailsDeveloper]

Cambridge is nice for prototyping, but I'm in doubt if the html-
designer will understand constructs like tags oder includes. In this
case the template couldn't be easily opened in a browser.
On the other hand Scala and japid are type-safe, which is a big
advantage in development. Unfortunately there is no template system
with code-completion in the eclipse-editor :-/

Niels

On 29 Jun., 12:39, Ivan Meredith <i...@ivan.net.nz> wrote:
> Then the answer is probably just use cambridge?
>
> I personally don't like the way cambridge does things, but hey, play has 4
> (maybe more?) great templating options so just pick the one that suits your
> work flow. There is definitely not one 'right' way of doing things.
>

> On 29 June 2011 21:45, Rakesh Waghela <javain...@gmail.com> wrote:
>
> > Cambridge Template author has explained this pain in his goals..
>

> >http://code.google.com/p/cambridge/wiki/TemplateAuthorsGuide#What_is_...
> > ?

> > What is Cambridge?
>
> > Cambridge is a Template Engine for generating Markup Languages. It can be
> > used to render web (html) pages or to generate xml documents or even for
> > generating plain text with dynamic data in it. It can be used as an
> > alternative to other Templating solutions for Java like JSP, Freemarker or
> > Velocity.
>
> > What makes Cambridge different than other template engines?
>

> >    - The template files are pure html documents. You can edit them using

> >    any authoring tool or open them in your browser and it will be rendered
> >    correctly.

> >    - Less cluttered. You don't need to add any external tags or scripts

> >    into your template files. Cambridge knows the dom structure of your document
> >    and uses the scopes of your existing tags to identify where a dynamic
> >    behavior will be effective. (This doesn't mean that the templates have to be
> >    valid XML documents.) All you need to do as a developer is to add attributes
> >    to your existing tags.

> >    - Cambridge is highly extensible. You can write your own behaviors,

> >    functions, tags. You can select from a list of different expression
> >    languages to use.

> >    - Supports Template inheritance. Cambridge templates can extend other

> >    templates to override some tags that are defined in parent templates. This
> >    is much more convenient than just using includes which are also supported.

> >    - Provides a DOM like Java API to modify tag structure of the

> >    templates. This way you can convert a completely static html file into a
> >    dynamic template using the Java API.

> >    - Supports popular web frameworks. You can use Cambridge with Servlets,