oh i see now. Indeed. Awesome and neat. Let sleep on it for now.
> ... but, I think the implementation might be easier than statically compiling the standard templates. At least i can say two things by now, lots of fun, its a breaking go api change >.< On Tuesday, December 20, 2016 at 2:30:19 PM UTC+1, Egon wrote: > > > > 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.
