v0.12

[brendensoares]

No description provided.

[brendensoares]

@AnonX we should have releases for this repo like we do in the core revel repo, agreed? I've merged it for now.

[ghost]

@brendensoares Ideally I would like to see revel/cmd as an independent repo. But right now it's not. So, yes. I have to agree.

[ghost]

@brendensoares By the way, I'd like to know more about your plans regarding revel/cmd. If I recall correctly you said somewhere you wanted revel command to be optional. Not sure, though.

[brendensoares]

@AnonX That's a great topic for our next team meeting. I've started a list of agenda items in our meeting notes wiki page. @revel/core please add more. I'd like to have the meeting this Friday at about 7pm GMT-8. Who can join?

[notzippy]

@brendensoares Cannot make it at that time, I am in PDT and that is 6pm family supper time, either 2 hours later or earlier would work. I can just leave my IRC channel open and read the notes though..

[ghost]

@brendensoares I'm in. Any time is good.

[brendensoares]

@notzippy I would really like to do a Google hangout as screen sharing and voice chat is a huge communication boost. To start, I'm fine with using IRC, but if we're all really committed to getting Revel going at full steam, then we need to go all in.

I think we should create a temporary IRC channel such as #revelcore for our meetings. We'll also publish our meeting notes on our wiki.

@AnonX excellent.

[notzippy]

@brendensoares You hadn't mentioned what form the meeting would be in so I had assumed irc... I can do a hangout or utox if you really want privacy.. That time slot I cannot do though, earlier or later works. Sorry

[brendensoares]

@notzippy Sorry, my fault, I am PDT, too (Vegas), I just thought we were same as PST/GMT-8 right now, not PDT.

How is 7/8pm your time (and mine), PDT? @revel/core ?

As far as the medium, I don't care. Privacy is not important to me, especially in the context of an open source project, but I'd be willing to give it a shot. I've heard of Tox, but never used it. Let's give it a shot. It looks like a neat solution, but does it allow desktop sharing? We can use Mikogo for that if needed.

[ghost]

Sorry, looks like I cannot take part in the meeting as @brendensoares said I should work rather than running revel during the day 😄.

But I have some ideas on how to restructure revel and turn it into simple, modular, clean Go wayish solution. I'll prepare a presentation and show it to you (pictures and few words are more interesting than text, right?). Actually, I wanted to create my own framework. But if you're open to fundamental changes it would be cool to implement them here.

[notzippy]

@AnonX I am also thinking along the lines of modularity and looking forward to see how your thoughts align with mine 👍

@brendensoares Has anyone else confirmed for the meeting tonight ?

[brendensoares]

@notzippy just you and @AnonX. @pedromorgan is MIA. This is the battle we have to overcome; working together toward a unified goal.

@AnonX are you joining our meeting or no? I knew I shouldn't have asked you any personally identifying questions; conflicts too much with your need to feel anonymous 👅

@AnonX @notzippy I'm open to restructuring if it improves the perceived workflow of Revel. I, like you 2, want Revel to enable a fast development cycle by using common conventions, e.g. MVC. I don't think a microframework structure can scale well for large apps. Sinatra is great for quick hacking, but Rails has its popularity for a reason: rapid application development. I want to take as many good ideas from other frameworks as possible and I could care less about Go idioms since they are highly subjective. I plan on using reflection no matter what the purists say. I have no problem incorporating revel cli into my workflow no matter what the purists say. As long it make practical sense and allows me to enjoy the process of creating digital solutions to real world problems. I want to create and be creative; that is why I chose to be a programmer.

I really hope we can get into a good groove and not let the roadmap drown us in decisions. @AnonX I really hope you join us tonight at 8pm PDT. 👍

[ghost]

@brendensoares Being idiomatic, modular and simple doesn't mean it has to be less productive.
I didn't have enough time to prepare a clear presentation, so I'll just share my thoughts here.

The architecture Revel Framework has now:

• revel package plays a central role.
  • It accumulates everything (configs, routes, info about controllers from auto generated files) inside.
  • And developers import it just as a big magic box and rely on revel docs and source code to make sure they are using it correctly.
  • Meanwhile, things are becoming more and more complex. Order of initialization of different variables / calls of functions, and stuff like that. How many issues related to that did we have?
• revel/cmd is used for creation of skeleton app, running & rebuilding process, packaging, starting integration tests, analysing controllers package's files, generation of main.go and routes.go. Way too many functions.
• revel and revel/cmd are tightly coupled.
• Filters: wanna create Session filter? Please, add Session global variable to revel package. Flash? Do the same.
• revel/cmd scans hard coded paths and generates files in a format:
  
  There is no way to somehow modify this process. Even if you really need it. Just rely on the magic box.

Illustration of current architecture:

My proposal includes:

• revel/cmd is just a simple task runner and files watcher:
  • It reads .revel.yml in the root directory of your project and decides what it should watch and what actions perform. For example, go generate & go build & go run on update of app/controllers/*.go files. BTW It can also be used for assets recompilation.
• We have server.go file in the root directory of our project (or in app). It includes the following comment:

//go:generate revel generate handlers -c github.com/anonx/sample/app/controllers -v github.com/anonx/sample/app/views -h github.com/anonx/sample/app/handlers

So, after every go generate revel generate handlers subcommand will be called with the arguments above. It will analyse requested controllers package and generate a handlers package. Just usual handlers (rather than some calls to revel.RegisterController) that can be used without revel framework, like:

package handlers

import (
    "github.com/anonx/sample/app/controllers"
)

// AppIndex is just a sample.
func AppIndex(w http.ResponseWriter, r *http.Request) {
    c := &controllers.App{}
    c.Initialize(w, r)

    // Do you remember the plans about magic Before, After, etc. methods
    // instead of interceptors?
    defer c.Finally()
    c.Before()

    // Call Index action.
    c.Index()

    c.After()
}

• Same is for routes, a file of the following format will be generated if we include go generate revel generate routes -h ... -r ...:

package routes

import (
    "github.com/anonx/sample/app/handlers"
)

Context := httprouter.New()
Context.GET("/", handlers.AppIndex)

• In our server.go we will have to include just one line (it is actually already included by-default):

http.ListenAndServe(conf.StringDefault("http.addr"), routes.Context)

Illustration of a new architecture:

So, we are still using reflection. But it is develop time reflection, not runtime one (at least, where possible).

Revel is still high level, but focus is on developer's app rather than on revel package. If they do not like our handlers generator, they will implement their own. Not satisfied with router generator? No, problem. Use your own. Don't like the standard files & dirs layout, modify go:generate comments in server.go. Wanna recompile coffee files on their update? Yes, sir.

My message is too long, so I'll not include details about filters. But I think they were not supposed to be used for Revel's extendibility. They are more kind of for structuring framework's code at an early stage of development when it is not clear yet what to do with the architecture. So, kind of short term solution for framework's developer himself. And if we want to promote it as a way of extendibility, we should come up with an idea of a better approach.

[brendensoares]

I agree with most everything you're saying. Flexibility and simplicity are key indicators of good code quality and your general direction is spot on.

Filters are present to allow easy manipulation of the HTTP request and response. I don't think they exist to help develop Revel as a framework. I do see value in making certain things part of Revel, but that doesn't make filters a bad design choice. Modular code is good.

I have more to say about your awesome diagrams.

[notzippy]

One of the primary reasons why I choose Revel was the way it supported modules, making them (almost) first class containers. To me a bright future for Revel relies on keeping this advantage. If you needed an authentication package - just add this module, if you needed a forum add this module, etc. etc. What I am struggling with your diagrams is how modules will fit into this scheme. Are pluggable modules going to be part of this ? Will you be able to override views like you can currently ?

[brendensoares]

@notzippy I agree that modules, aka modular code, is very valuable. I don't see any reason modular loading can't stay with what @AnonX is proposing.

@AnonX your diagrams need some clarification, but I like them a lot. Good stuff!

I'm not a huge fan of plug and play frameworks in the sense that you can use only the pieces you want. It's one thing to have a core with optional modules, but I think it complicates the implementation by not having guaranteed assumptions always true. For example, the file structure is a big part of what make a Revel app different from other Go web apps; it's a convention, that once learned, can be taken for granted as always true. If a developer has worked with Revel before, then they can work on any Revel apps, because they follow certain conventions. So there is value in optional modules, but we do need a fixed, static core.

I like the idea of a handlers package. I think this will make Revel's request flow a lot clearer and less magical. Let me point out that I think magic is a very good thing, but when you want to understand the magic trick, it shouldn't be difficult. Conventions are magical and very useful.

I haven't worked with go:generate, but I didn't think we could make use of it. Looking at it now, it looks perfect for what you're proposing.

revel/cmd is already modular in implementation and code organization, but it sounds like you want to make it support runtime scripting of sorts. I'd like to hear more about this.

Action Items

This thread has gone off topic from its initial purpose. Let's end it here and make forward progress on this proposal. I'm going to refer to this proposal as micro Revel, because it is breaking up our current monolithic design into more concise components.

• Create micro branches in revel/revel and revel/cmd
• Create a RFC for this proposal to start gathering feedback and creating a consensus on the direction we want to go.
  • We need to ensure that micro restructuring will be backwards compatible with our current app directory structure. I am open to modifying the underlying implementation, but I'd like to avoid as many interface changes as possible. This should be a high level goal. We can make special exceptions where the value is substantial.
• Start coding a proof of concept for this proposal!

[brendensoares]

@notzippy I see your concern about modules.

@AnonX I don't think your new proposal will support modules as we currently have them.

Currently, revel takes an importPath as a parameter which allows it to load modules at runtime as defined in the app.conf. Can you describe how a revel app can include a module in your proposal?

[notzippy]

Here is a quick sketch of my thoughts of an ideal running app

[ghost]

Filters are present to allow easy manipulation of the HTTP request and response. I don't think they exist to help develop Revel as a framework. I do see value in making certain things part of Revel, but that doesn't make filters a bad design choice. Modular code is good.

@brendensoares I didn't say we do not need filters. The idea is filters we have are not good. Mainly because they cannot create their own variables. Here is a possible solution:

We may have init.go that contains:

type Controller struct {
    *revel.Controller
    *session.Filter
    *session.FlashFilter
}

So, filters are in the form of controllers. Every of them has Before, After, Panic, and Finally methods.
And user's app.go will look like:

type App struct {
    Controller // Embed local controller rather than revel.Controller.
}

For example, the file structure is a big part of what make a Revel app different from other Go web apps; it's a convention, that once learned, can be taken for granted as always true.

No, it's not a convention. Right now it's a hard coded requirement. And this proposal is about making it a convention.

When the convention implemented by the tool matches the desired behavior, it behaves as expected without having to write configuration files. Only when the desired behavior deviates from the implemented convention is explicit configuration required.

Wikipedia.

revel new ... will generate app as we have it now. With all the directories and with the same dirs & files structure (which is conventional). And as it is just a convention user is able to modify things if he/she has such a need.

I like the idea of a handlers package. I think this will make Revel's request flow a lot clearer and less magical. Let me point out that I think magic is a very good thing, but when you want to understand the magic trick, it shouldn't be difficult. Conventions are magical and very useful.

It still will be magical for those for whom it's OK. And users who'd like more control will get it.

I don't think your new proposal will support modules as we currently have them.

Why not? revel generate routers will generate for you whatever you want.
-Dear, revgen, can you scan routes and app.conf and give us the result we want, please?
-Yes, my general. I am a stupid machine. I'll do whatever you ask.