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. 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.
