I am diving further into Hugo. Now I can read configuration, I am close to pass data to hugolib/hugo_sites.go.
On the template side, I can catch the {{ widgets "mywidgetarea" }} statement inside template and render some HTML. I also created an internal shortcode that enables using {{< widgets … >}} inside content from any project.
Now on, I want to cross the bridge and pass some template.HTML to the templates so as to be able to manage that inside tpl/template_funcs.go. But I am not sure what is the best for that (and I am not sure to fully understand how that works). I understand all template calls are made from hugolib/hugo_sites.go, so I guess I have to work from there to add something to a data structure inside tpl/something.go…
EDIT: Also, as .Sites is accessible within the templates themselves, is it possible (and nice) to return something like "{{ .Site.myvariable }}" from the tpl/template_funcs function I wrote?
I haven’t looked closely at your work, but it looks like your widget func is trying to reinvent the Go templates. Widgets is, in my head, all about template composition, and should be built upon the ideas from partials and blocks etc. But as I said, I haven’t spent much thought on this. Just wanted to give you a heads up, as to not spending too much time on a path that isn’t going to get merged into Hugo.
Sure! Thanks @bep for your reaction. But do you mean on a path that would not be merged in that case, or on a path that won’t in any case get merged?
About this process, actually I barely have had a reaction from the core maintainers, so I cannot know what the whole staff is thinking about this, and what is the right process on this project to implement things.
The very reason why I took several hours to write this post and this one is precisely, as you asked me, was to make a proposal and to get it discussed. Then, the only reaction I had was the chief maintainer of the project saying he had not read all of it and talking about another (kind!) improvement. I am absolutely conscious that we are all benevolent here, and that is why I am not demanding reaction. Or at least a “we’ve discussed it, and NO” or “yes ok do it”, or “Seen and discussed, and we wil implement that ourselves”. But it is actually twenty-eight days since I have been hoping for a reaction from the staff.
Since there has not been any, I am then trying to get things done by myself. I assume this is a way to go on. I would have loved to discuss on this functionality — needs, opportunities, implementation, and so on. Now that I am trying to implement it, this is precisely a place where to talk about design and I am happy for it! But of course, having discussed this before would have ensured the design pattern was correct. I am currently trying to do things the way I can in a new project, with a new programming language and all this!!
Now about template composition I totally agree with you. Note that this is a personal draft, and for now I have hardcoded some return values as a milestone for my development. When I will see <strong>widget area (from hugolib/widget.go): … </strong> in my page I will go on.
But I don’t know if it is what you saw or if it really is the design pattern…?
I feel your pain about getting no reactions to you proposal and your work. This is a @spf13 project, and he should talk about the big lines. I’m currently heavily involved in a big rewrite of regular pages vs the nodes (home page etc.) and widget is not something I care too much about at the moment. I agree that it is important, but Hugo needs some core building blocks in place first.
I’m the project leader when it fits my agenda I would only continue if you’re ready to throw most of it away – or use it in your own fork, or as a learning experience.
My main point is this: I have a limited set of time to spend on Hugo, and that is currently booked on more important stuff.
@lebarde If you are interested in the more UNIX-y framework built on top of Hugo that we mentioned in the other thread, I’m happy to team up. That said, my conventions for things like class names, etc, are going to be decidedly in English, which might not dovetail with Hugo’s international appeal. I’d want to follow a well-established model so that we have to think about less to get up and running. I’m not suggesting the BEM build tools necessarily, but I think this is a good approach to conventions:
It also doesn’t have to be that exhaustive either. Maybe just a set of partials/shortcodes aimed at targeting common uses cases we pick up from the forums. And it also doesn’t need to be exactly like Octopress (as you’ll see there are many shortcomings. I think the changes that @bep is making to nodes could make an effort like this a lot easier.
I would only continue if you’re ready to throw most of it away – or use it in your own fork, or as a learning experience.