> At the cost of throwing internationalisation out of the window. At least the example you led with is more conducive to localisation.
Right. i18n is the reason you have to import two taglibs and the template doesn't support basic conditionals.
/s
JSP is horrendous. There is not a single reason for its existence, and it should be quarantined.
As far as i18n/l10n goes, the example I quoted was from play framework. This is how an internationalized version will look like:
# Messages file
unread_emails=You have %s %s
no_email=You have no email
# Template
#{if (emails.unread) }
&{'unread_emails', emails.unread, emails.unread?.pluralize('email')}
#{/if}
#{else}
&{'no_emails'}
#{/else}
Are you arguing internationalized jsp is somehow better than this? I tried really hard, but I failed to think of a single templating engine that's worse than JSP.
I like JSPX. Designers and HTML front-end engineers intuitively understand custom tags, and any imperative non-declarative logic should ideally be pushed back into Java or a custom JSP tag, such that you rarely see it.
> Designers and HTML front-end engineers intuitively understand custom tags, and any imperative non-declarative logic should ideally be pushed back into Java or a custom JSP tag, such that you rarely see it.
Have you used other templates say Jinja2 or Django templates? The traits you listed aren't unique to JSPX. Jinja2 is designer friendly, doesn't have non-declarative logic, and is pleasant and concise to use.
ERB(or slim or haml) allows embedding code in templates, but that doesn't mean you are mandated to do it. Java will allow you to put n non-public classes in one file - that doesn't mean you code your whole app in a single .java file. Just because it's possible is hardly an excuse for it being bad.
There are use-cases where code in templates are useful. I would rather not jump through the hoops of defining a custom tag for an one-off use-case.
The choice is less clear obvious when you've started to ask why use server-side templating at all? I've spent quite a bit of time on both Rails and Java webapps. The conclusion I've come to is I'd really rather the server just returned JSON and rendering happened client-side. I'm not working on Twitter-scale stuff, though.
Right. i18n is the reason you have to import two taglibs and the template doesn't support basic conditionals. /s
JSP is horrendous. There is not a single reason for its existence, and it should be quarantined.
As far as i18n/l10n goes, the example I quoted was from play framework. This is how an internationalized version will look like:
Are you arguing internationalized jsp is somehow better than this? I tried really hard, but I failed to think of a single templating engine that's worse than JSP.