On Tuesday, 20 December 2016 14:30:28 UTC+2, Egon wrote: > > On Tuesday, 20 December 2016 13:07:05 UTC+2, mhh...@gmail.com wrote: >> >> That s interesting too, but it kills all the flexibility provided by >> template package. >> >> I mean, the button component i used as an example totally fits your DSL >> approach, >> but, this component extremely well defined in terms of both go structure >> and html structure, >> is quiet limited, IMHO. >> >> See this template, do i really want to declare div and class and all with >> go code, >> which will be twice more longer to write and infinitely more static ? >> >> The component approach serve a great purpose of re usability, >> and two specific things, translation, error management. >> >> Besides that it s a burden to develop.... TBH. So i would rather not do >> it all in go, neither do it all in template. >> > > Sure, use whatever makes most sense to you. > > ... but, I think the implementation might be easier than statically > compiling the standard templates. >
And an incorrectly-escaping implementation https://github.com/egonelbre/exp/tree/master/htmlrender > Two examples how the final could look like: > * https://play.golang.org/p/L8KbfDV_pV > * https://play.golang.org/p/8H8Zw1SPPg > > >> {{define "app/login"}} >> <form name="login" method="POST" >> action="{{.Component.PostUrl}}" >> post-notify=".custom-expander-notifier" >> class="custom-js-form-ajax"> >> <div class="mdl-card mdl-shadow--4dp" style="width:100%;"> >> <div class="mdl-card__title"> >> {{.Component.Title.Render}} >> </div> >> <div class="mdl-card__media"> </div> >> <div class="mdl-card__media >> mdl-color--blue-grey-50 failure >> custom-js-expander custom-expander custom-expander-notifier >> {{if .Component.Failure.Error}}is-expanded{{end}} >> "> >> <div class="mdl-card__supporting-text >> mdl-color-text--primary-dark >> custom-expander-container"> >> <div> >> <span class="failure-text custom-expander-message"> >> {{.Component.Failure.Render}} >> </span> >> <br/> >> {{.Component.TryAgain.Render}} >> </div> >> </div> >> </div> >> <div class="mdl-card__supporting-text"> >> {{.Component.Username.Render}} >> {{.Component.Password.Render}} >> </div> >> <div class="mdl-card__actions" style="text-align:right"> >> {{.Component.Submit.Render}} >> </div> >> </div> >> </form> >> {{end}} >> >> >> >> >> >> On Monday, December 19, 2016 at 12:48:36 PM UTC+1, Egon wrote: >>> >>> >>> >>> On Monday, 19 December 2016 13:04:23 UTC+2, mhh...@gmail.com wrote: >>>> >>>> hi, thanks. >>>> >>>> tbh, i m not sure i feel like i want to do php-like dev in go. >>>> I m not even certain that the apparent gain in flexibility and speed of >>>> development really worth it. >>>> Guts tell me this is like giving the wrong tools to the wrong worker to >>>> do the wrong job. >>>> A front end dev won t really benefit of such powerfull templates, and >>>> it could probably >>>> give him way more hard time than benefits, a backend dev does not >>>> really benefit of such >>>> intrusion of his code into the presentation layer, he usually is not so >>>> good in design. >>>> Also, i don t think it helps to solve the general problem of go with >>>> templating, >>>> express similarities but yet avoid duplication, when you develop a >>>> backend >>>> you have hundreds of pages very similar to each other, a table of users >>>> or a table of blog posts >>>> its a table after all, except those little differences in the number >>>> and types of column, >>>> which go really is not good to manage, because their are totally >>>> different according to its type model. >>>> Giving more responsibility and power to the presentation, to me, really >>>> does not sound to be a way to solve that. >>>> Recently i worked on a component oriented approach with a clear >>>> separation of concerns >>>> between the client and server domains, i found it was a good fit >>>> between all parameters i identified >>>> and felt concerned with. >>>> yet i guess we agree to say its a waste to loose so much machine >>>> resource >>>> with the current implementation of templates, even though, >>>> and as often with go, there are lots of great and awesome properties in >>>> it. >>>> >>> >>> Just a note, you can also think of working with a custom DSL, rather >>> than working with templates or io.Writer directly... e.g: >>> >>> type Table struct { >>> Rows []struct{ >>> Cells []ui.Renderer >>> } >>> } >>> >>> func (table *Table) Render(w ui.Writer) { >>> defer w.Wrap("table")() >>> for _, row := range table.Rows { >>> w.Start("tr") >>> for _, cell := range row.Cells { >>> w.Start("td") >>> cell.Render(w) >>> w.End("td") >>> } >>> w.End("tr") >>> } >>> } >>> >>> type CustomLink struct { >>> Name ui.TextContent >>> ID ui.ID >>> Class ui.ClassList >>> URL ui.URL >>> >>> Disabled bool >>> } >>> >>> func (link *CustomLink) Render(w ui.Writer) { >>> if !link.Disabled { >>> defer w.Wrap("a")() >>> link.URL.Render(w) >>> } else { >>> defer w.Wrap("span")() >>> } >>> >>> link.ID.Render(w) >>> link.Class.With("my-custom-link").Render(w) >>> link.Name.Render(w) >>> } >>> >>> + Egon >>> >>> >>>> On Monday, December 19, 2016 at 8:11:51 AM UTC+1, Aliaksandr Valialkin >>>> wrote: >>>>> >>>>> Take a look at https://github.com/valyala/quicktemplate . Though it >>>>> is incompatible with template/html sytax, it provides static template >>>>> compilation, high performance and go-like syntax. >>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
