[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-22 Thread mhhcbon 
I could not understand, at all, the prolog, but you left a cool link to 
learn more about it, thanks!

I was referring to https://en.wikipedia.org/wiki/Edge_Side_Includes

Where instead of calling for a `template "a" params...` instruction,
i imagine an `esi_template "a" params...`, which would automatically
toggle the template depending on the request content (esi req header), 
either,
to an esi node for future processing by the proxy (varnish for example), 
or its content, as instructed by the request.

Obviously go is perfectly able to implement such thing today, 
by hands and duplication,
the idea would be to automate it and simplify it as much as possible.



On Friday, December 23, 2016 at 12:24:21 AM UTC+1, Egon wrote:
>
> On Friday, 23 December 2016 01:00:29 UTC+2, mhh...@gmail.com wrote:
>>
>> Not sure i quiet get your meaning about symbolic evaluation, 
>>
>
> It just reminded me how you can do expression simplification in Prolog and 
> LISP.
>
> * http://stackoverflow.com/a/3516781/192220
> * https://mitpress.mit.edu/sicp/
>  
>
>> or it s just what i did :x
>>
>> Anyways, for whoever else interested
>> https://github.com/mh-cbon/template-tree-simplifier 
>> 
>>
>> I was wondering if you have any thoughts regarding the idea to 
>> generate the go code not via string manipulation but
>> via the go ast capabilities.
>>
>> https://golang.org/pkg/go/ast/
>>
>
> Working with text/template (or just printing) + go/format is much easier.
>
> Using go/ast might make sense when you are rewriting based on some rules, 
> but not for generating code from scratch.
>  
>
>> I saw there is a printer. I m not quiet sure yet how this going to turn,
>> but i felt i was needing a sort of structure to store types of the data
>> while generating go code, which was not available when i used text 
>> processing.
>>
>> I don t want to abuse, but i was also wondering if ESI processing was 
>> waking up any of your hears.
>>
>
> I'm not quite sure what you are referring to?
>  
>
>> As i feel more & more confy with the template package i begin to think 
>> about this.
>>
>> you or anyone else.
>>
>> thanks!
>>
>> On Thursday, December 22, 2016 at 7:55:10 AM UTC+1, Egon wrote:
>>>
>>>
>>>
>>> On Wednesday, 21 December 2016 23:34:54 UTC+2, mhh...@gmail.com wrote:

 Hi,

 back on my initial question about compiling template, i m looking for 
 some experienced ideas.

 I have now found out i needed to change the ast tree of template in 
 order to simplify it for later manipulation.

>>>
>>> The easiest way I can think of is trying to do it in terms of 
>>> symbolically evaluating of the tree and using the actions as the new tree.
>>>
>>> https://play.golang.org/p/i-QY-7wJYq
>>>
>>> Obviously doing the same on the actual structure is more annoying.
>>>
>>>
 So for example i transform this
 {{ ("what" | up) | lower }}
 into
 {{ $some := ("what" | up) }}
 {{ $some | lower }}

 And so on, i d like to reach 
 {{ $some := up "what" }}
 {{ lower $some }}

 Which will be as close as possible to regular go code.

 The thing is that the process to do those transformations seems pretty 
 fragile and tedious.

 I have tree like this
  parse.Tree
parse.ActionNode
 parse.PipeNode
  parse.CommandNode
   parse.IdentifierNode Ident="up"
   parse.StringNode Quoted="\"some\"" Text="some"
parse.TextNode Text="\n"
parse.ActionNode
 parse.PipeNode
  parse.CommandNode
   parse.StringNode Quoted="\"some\"" Text="some"
  parse.CommandNode
   parse.IdentifierNode Ident="split"
   parse.PipeNode
parse.CommandNode
 parse.PipeNode
  parse.CommandNode
   parse.StringNode Quoted="\"what\"" Text="what"
  parse.CommandNode
   parse.IdentifierNode Ident="lower"
parse.CommandNode
 parse.IdentifierNode Ident="up"
parse.TextNode Text="\n"

 to simplify, one of the algorithm consist of browsing the structure 
 until it match a Pipe containing a Cmd with an Identifier after a Cmd 
 with a Pipe
 that would match *("what" | lower) | up*

 And so on to simplify more and more the tree.

 I wonder if there are better ways to achieve this kind of transform.

>>>

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-22 Thread Egon 
On Friday, 23 December 2016 01:00:29 UTC+2, mhh...@gmail.com wrote:
>
> Not sure i quiet get your meaning about symbolic evaluation, 
>

It just reminded me how you can do expression simplification in Prolog and 
LISP.

* http://stackoverflow.com/a/3516781/192220
* https://mitpress.mit.edu/sicp/
 

> or it s just what i did :x
>
> Anyways, for whoever else interested
> https://github.com/mh-cbon/template-tree-simplifier 
> 
>
> I was wondering if you have any thoughts regarding the idea to 
> generate the go code not via string manipulation but
> via the go ast capabilities.
>
> https://golang.org/pkg/go/ast/
>

Working with text/template (or just printing) + go/format is much easier.

Using go/ast might make sense when you are rewriting based on some rules, 
but not for generating code from scratch.
 

> I saw there is a printer. I m not quiet sure yet how this going to turn,
> but i felt i was needing a sort of structure to store types of the data
> while generating go code, which was not available when i used text 
> processing.
>
> I don t want to abuse, but i was also wondering if ESI processing was 
> waking up any of your hears.
>

I'm not quite sure what you are referring to?
 

> As i feel more & more confy with the template package i begin to think 
> about this.
>
> you or anyone else.
>
> thanks!
>
> On Thursday, December 22, 2016 at 7:55:10 AM UTC+1, Egon wrote:
>>
>>
>>
>> On Wednesday, 21 December 2016 23:34:54 UTC+2, mhh...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> back on my initial question about compiling template, i m looking for 
>>> some experienced ideas.
>>>
>>> I have now found out i needed to change the ast tree of template in 
>>> order to simplify it for later manipulation.
>>>
>>
>> The easiest way I can think of is trying to do it in terms of 
>> symbolically evaluating of the tree and using the actions as the new tree.
>>
>> https://play.golang.org/p/i-QY-7wJYq
>>
>> Obviously doing the same on the actual structure is more annoying.
>>
>>
>>> So for example i transform this
>>> {{ ("what" | up) | lower }}
>>> into
>>> {{ $some := ("what" | up) }}
>>> {{ $some | lower }}
>>>
>>> And so on, i d like to reach 
>>> {{ $some := up "what" }}
>>> {{ lower $some }}
>>>
>>> Which will be as close as possible to regular go code.
>>>
>>> The thing is that the process to do those transformations seems pretty 
>>> fragile and tedious.
>>>
>>> I have tree like this
>>>  parse.Tree
>>>parse.ActionNode
>>> parse.PipeNode
>>>  parse.CommandNode
>>>   parse.IdentifierNode Ident="up"
>>>   parse.StringNode Quoted="\"some\"" Text="some"
>>>parse.TextNode Text="\n"
>>>parse.ActionNode
>>> parse.PipeNode
>>>  parse.CommandNode
>>>   parse.StringNode Quoted="\"some\"" Text="some"
>>>  parse.CommandNode
>>>   parse.IdentifierNode Ident="split"
>>>   parse.PipeNode
>>>parse.CommandNode
>>> parse.PipeNode
>>>  parse.CommandNode
>>>   parse.StringNode Quoted="\"what\"" Text="what"
>>>  parse.CommandNode
>>>   parse.IdentifierNode Ident="lower"
>>>parse.CommandNode
>>> parse.IdentifierNode Ident="up"
>>>parse.TextNode Text="\n"
>>>
>>> to simplify, one of the algorithm consist of browsing the structure 
>>> until it match a Pipe containing a Cmd with an Identifier after a Cmd 
>>> with a Pipe
>>> that would match *("what" | lower) | up*
>>>
>>> And so on to simplify more and more the tree.
>>>
>>> I wonder if there are better ways to achieve this kind of transform.
>>>
>>

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-22 Thread mhhcbon 
Not sure i quiet get your meaning about symbolic evaluation, 
or it s just what i did :x

Anyways, for whoever else interested
https://github.com/mh-cbon/template-tree-simplifier

I was wondering if you have any thoughts regarding the idea to 
generate the go code not via string manipulation but
via the go ast capabilities.

https://golang.org/pkg/go/ast/

I saw there is a printer. I m not quiet sure yet how this going to turn,
but i felt i was needing a sort of structure to store types of the data
while generating go code, which was not available when i used text 
processing.

I don t want to abuse, but i was also wondering if ESI processing was 
waking up any of your hears.
As i feel more & more confy with the template package i begin to think 
about this.

you or anyone else.

thanks!

On Thursday, December 22, 2016 at 7:55:10 AM UTC+1, Egon wrote:
>
>
>
> On Wednesday, 21 December 2016 23:34:54 UTC+2, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> back on my initial question about compiling template, i m looking for 
>> some experienced ideas.
>>
>> I have now found out i needed to change the ast tree of template in order 
>> to simplify it for later manipulation.
>>
>
> The easiest way I can think of is trying to do it in terms of symbolically 
> evaluating of the tree and using the actions as the new tree.
>
> https://play.golang.org/p/i-QY-7wJYq
>
> Obviously doing the same on the actual structure is more annoying.
>
>
>> So for example i transform this
>> {{ ("what" | up) | lower }}
>> into
>> {{ $some := ("what" | up) }}
>> {{ $some | lower }}
>>
>> And so on, i d like to reach 
>> {{ $some := up "what" }}
>> {{ lower $some }}
>>
>> Which will be as close as possible to regular go code.
>>
>> The thing is that the process to do those transformations seems pretty 
>> fragile and tedious.
>>
>> I have tree like this
>>  parse.Tree
>>parse.ActionNode
>> parse.PipeNode
>>  parse.CommandNode
>>   parse.IdentifierNode Ident="up"
>>   parse.StringNode Quoted="\"some\"" Text="some"
>>parse.TextNode Text="\n"
>>parse.ActionNode
>> parse.PipeNode
>>  parse.CommandNode
>>   parse.StringNode Quoted="\"some\"" Text="some"
>>  parse.CommandNode
>>   parse.IdentifierNode Ident="split"
>>   parse.PipeNode
>>parse.CommandNode
>> parse.PipeNode
>>  parse.CommandNode
>>   parse.StringNode Quoted="\"what\"" Text="what"
>>  parse.CommandNode
>>   parse.IdentifierNode Ident="lower"
>>parse.CommandNode
>> parse.IdentifierNode Ident="up"
>>parse.TextNode Text="\n"
>>
>> to simplify, one of the algorithm consist of browsing the structure 
>> until it match a Pipe containing a Cmd with an Identifier after a Cmd 
>> with a Pipe
>> that would match *("what" | lower) | up*
>>
>> And so on to simplify more and more the tree.
>>
>> I wonder if there are better ways to achieve this kind of transform.
>>
>

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-21 Thread Egon 


On Wednesday, 21 December 2016 23:34:54 UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> back on my initial question about compiling template, i m looking for some 
> experienced ideas.
>
> I have now found out i needed to change the ast tree of template in order 
> to simplify it for later manipulation.
>

The easiest way I can think of is trying to do it in terms of symbolically 
evaluating of the tree and using the actions as the new tree.

https://play.golang.org/p/i-QY-7wJYq

Obviously doing the same on the actual structure is more annoying.


> So for example i transform this
> {{ ("what" | up) | lower }}
> into
> {{ $some := ("what" | up) }}
> {{ $some | lower }}
>
> And so on, i d like to reach 
> {{ $some := up "what" }}
> {{ lower $some }}
>
> Which will be as close as possible to regular go code.
>
> The thing is that the process to do those transformations seems pretty 
> fragile and tedious.
>
> I have tree like this
>  parse.Tree
>parse.ActionNode
> parse.PipeNode
>  parse.CommandNode
>   parse.IdentifierNode Ident="up"
>   parse.StringNode Quoted="\"some\"" Text="some"
>parse.TextNode Text="\n"
>parse.ActionNode
> parse.PipeNode
>  parse.CommandNode
>   parse.StringNode Quoted="\"some\"" Text="some"
>  parse.CommandNode
>   parse.IdentifierNode Ident="split"
>   parse.PipeNode
>parse.CommandNode
> parse.PipeNode
>  parse.CommandNode
>   parse.StringNode Quoted="\"what\"" Text="what"
>  parse.CommandNode
>   parse.IdentifierNode Ident="lower"
>parse.CommandNode
> parse.IdentifierNode Ident="up"
>parse.TextNode Text="\n"
>
> to simplify, one of the algorithm consist of browsing the structure 
> until it match a Pipe containing a Cmd with an Identifier after a Cmd with 
> a Pipe
> that would match *("what" | lower) | up*
>
> And so on to simplify more and more the tree.
>
> I wonder if there are better ways to achieve this kind of transform.
>

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-21 Thread mhhcbon 
Hi,

back on my initial question about compiling template, i m looking for some 
experienced ideas.

I have now found out i needed to change the ast tree of template in order 
to simplify it for later manipulation.

So for example i transform this
{{ ("what" | up) | lower }}
into
{{ $some := ("what" | up) }}
{{ $some | lower }}

And so on, i d like to reach 
{{ $some := up "what" }}
{{ lower $some }}

Which will be as close as possible to regular go code.

The thing is that the process to do those transformations seems pretty 
fragile and tedious.

I have tree like this
 parse.Tree
   parse.ActionNode
parse.PipeNode
 parse.CommandNode
  parse.IdentifierNode Ident="up"
  parse.StringNode Quoted="\"some\"" Text="some"
   parse.TextNode Text="\n"
   parse.ActionNode
parse.PipeNode
 parse.CommandNode
  parse.StringNode Quoted="\"some\"" Text="some"
 parse.CommandNode
  parse.IdentifierNode Ident="split"
  parse.PipeNode
   parse.CommandNode
parse.PipeNode
 parse.CommandNode
  parse.StringNode Quoted="\"what\"" Text="what"
 parse.CommandNode
  parse.IdentifierNode Ident="lower"
   parse.CommandNode
parse.IdentifierNode Ident="up"
   parse.TextNode Text="\n"

to simplify, one of the algorithm consist of browsing the structure 
until it match a Pipe containing a Cmd with an Identifier after a Cmd with 
a Pipe
that would match *("what" | lower) | up*

And so on to simplify more and more the tree.

I wonder if there are better ways to achieve this kind of transform.

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-21 Thread Egon 
On Tuesday, 20 December 2016 19:26:35 UTC+2, mhh...@gmail.com wrote:
>
> oh i see now. Indeed. Awesome and neat.
>

PS: forgot to mention, this can be mixed with templating as well. 

A declaration for some particular widget might be

var Button = ui.Template{"button.html"}
Button.RenderCustom(map[string]string{"title": "hello world"}, w)
// where you have
func (t *Template) RenderCustom(attributes map[string]string, w ui.Writer) 
{ ...

And the reverse as well, the widgets could have a method *HTML() 
template.HTML* or a global "Render(r ui.Renderer) template.HTML" in a 
FuncMap.


> 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"}}
   >>>   action="{{.Component.PostUrl}}"
   post-notify=".custom-expander-notifier"
   class="custom-js-form-ajax">
 
   
   {{.Component.Title.Render}}
   
   
   
 
   
 
   {{.Component.Failure.Render}}
 
 
 {{.Component.TryAgain.Render}}
   
 
   
   
 {{.Component.Username.Render}}
 {{.Component.Password.Render}}
   
   
 {{.Component.Submit.Render}}
   
 
   
 {{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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-20 Thread Egon 


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"}}
>>   >   action="{{.Component.PostUrl}}"
>>   post-notify=".custom-expander-notifier"
>>   class="custom-js-form-ajax">
>> 
>>   
>>   {{.Component.Title.Render}}
>>   
>>   
>>   
>> 
>>   
>> 
>>   {{.Component.Failure.Render}}
>> 
>> 
>> {{.Component.TryAgain.Render}}
>>   
>> 
>>   
>>   
>> {{.Component.Username.Render}}
>> {{.Component.Password.Render}}
>>   
>>   
>> {{.Component.Submit.Render}}
>>   
>> 
>>   
>> {{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
>>> IDui.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 
>

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-20 Thread Egon 
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"}}
>  action="{{.Component.PostUrl}}"
>   post-notify=".custom-expander-notifier"
>   class="custom-js-form-ajax">
> 
>   
>   {{.Component.Title.Render}}
>   
>   
>   
> 
>   
> 
>   {{.Component.Failure.Render}}
> 
> 
> {{.Component.TryAgain.Render}}
>   
> 
>   
>   
> {{.Component.Username.Render}}
> {{.Component.Password.Render}}
>   
>   
> {{.Component.Submit.Render}}
>   
> 
>   
> {{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
>> IDui.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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-20 Thread mhhcbon 
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.

{{define "app/login"}}
  

  
  {{.Component.Title.Render}}
  
  
  

  

  {{.Component.Failure.Render}}


{{.Component.TryAgain.Render}}
  

  
  
{{.Component.Username.Render}}
{{.Component.Password.Render}}
  
  
{{.Component.Submit.Render}}
  

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-19 Thread Egon 


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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-19 Thread mhhcbon 
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.

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.

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-18 Thread Aliaksandr Valialkin 
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.

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-18 Thread mhhcbon 
static escaping == great idea, but performance are strongly impacted.

As i worried about, the problem i m figuring now is that html package does 
not expose enough of its implementation.
for example most escape functions are private,
https://golang.org/src/html/template/escape.go#L48

But from what i try to do, it resumes to a func call, i don t have to re 
implement the context identifier, as its already done by the 
template.escape method (once the template is executed).

Anyway, i ll do some copy paste for instance, lets see, plenty of cases to 
manage before it can get useful.

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-18 Thread Egon 
On Sunday, 18 December 2016 11:16:23 UTC+2, mhh...@gmail.com wrote:
>
> Thanks a lot! I ve been playing a bit with it, for some simple cases it 
> worked great.
>
> Though, i looked into the html/template, am i correct to understand that 
> the html security layer consist of adding new cmds (of escaping) 
> on the relevant nodes ?
> https://golang.org/src/html/template/escape.go#L221
>
> Its all private, so i m bit concerned about how i m going to manage that.
>

Yeah, there are a lot of different rules for escaping -- you can take a 
look at 
https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html
 
for more information on sanitization.

But essentially, yes, to be fully compliant, you would need to reimplement 
the html/template package.

+ Egon

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

[go-nuts] Re: howto: compile template against well-known structure ?

2016-12-17 Thread Egon 


On Saturday, 17 December 2016 12:26:55 UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> I am wondering how i could compile html template against well-known 
> structures 
> to get better performance of it, but keep maintainability and security at 
> high levels.
>
> See this template 
>
> https://github.com/mh-cbon/mdl-go-components/blob/master/mdl/templates/button.tmpl
>
> And this implementation against its well known structure
>
> https://github.com/mh-cbon/mdl-go-components/blob/master/mdl/fast/render.go#L66
>
> My benchmark shows an awesome performance increase
>
> $ go test -bench=.
> BenchmarkRenderWithTemplate-4  3 56485 ns/op
> BenchmarkRenderWithFast-4200   968 ns/op
> PASS
> ok  command-line-arguments  4.989s
>
>
> But i don t feel like doing it by hands... Possible, but its an hard time 
> of maintenance and production.
>
>
> I hope and would like to have a program that would take a template and a 
> struct in input, 
> and produces a func or struct (whatever) in output.
>
> So I wonder if anyone could provide some tips and hints about automation 
> of such work,
> for instance i don t have any other clues other than getting wetting my 
> feet into the ast tree and playing with go generate.
>

The poc ast approach: https://play.golang.org/p/zn0ZFlVctn
Obviously would need a lot more cases to be fully compliant with 
html/template

+ Egon

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