The Phoenix Guides now live at https://github.com/phoenixframework/phoenix/tree/master/guides
Any issues and pull requests for the guides should be raised at https://github.com/phoenixframework/phoenix/issues
User guides for the Phoenix web development framework.
The Phoenix Guides now live at https://github.com/phoenixframework/phoenix/tree/master/guides
Any issues and pull requests for the guides should be raised at https://github.com/phoenixframework/phoenix/issues
We already have a placeholder file with a minimal outline - topics.md. Feel free to work with that outline or add topics as you see fit.
It might be the case that this would fit under the sockets guide - or not. Worth thinking about while writing.
use MyApp.Web, :view
reference: https://gist.github.com/chrismccord/cf51346c6636b5052885
API Docs link in header still links to 0.9.0, should link to 0.10.0
I'd like to voice concern over the nature of the channel guide. While I appreciate the desire to show what is happening on such a low-level I feel most people just won't care about the dispatching, etc... it might be best to show a more concise "here's how to implement channels" guide then the 2nd half of the guide can do more of the lower-level stuff in iex. As-is the current mix feels disjointed and muddies the message for those that just want to jump in.
The Elixir Dose links in the ecto-models guide is broken, know of any other links to add in until this guide is fleshed out?
just going through the guides trying to find where I can help out next, thought maybe I could work on the ecto guide, or do you have other suggestion?
Elixir Dose, Introduction to Ecto
Elixir Dose, Ecto With Phoenix, Part1
...
The example app name starts out as "PhoenixHello", then changes to Test on the "Templates" page.
Originally, I had thought that a page adding more detailed explanations of the tasks might be necessary, but I'm not sure this is necessary now. The routing guide covers the phoenix.routes task pretty thoroughly, and the readme talks about phoenix.new.
I vote for killing this page for now. Anybody else?
We already have a placeholder file with a minimal outline - sockets.md. Feel free to work with that outline or add topics as you see fit.
It might be the case that adding the channels and/or topics guides under sockets might make sense - or maybe not at all.
Complete the last two sections of the routing guide - scoped routes and channel routes.
We already have a placeholder file with a minimal outline - channels.md. Feel free to work with that outline or add topics as you see fit.
references:
https://gist.github.com/chrismccord/cf51346c6636b5052885
http://www.phoenixframework.org/v0.10.0/blog
In https://github.com/lancehalvorsen/phoenix-guides/blob/master/A_up_and_running.md it has the following suggested commands:
$ sudo apt-get install erlang-ssl
$ sudo apt-get install erlang-inets
On Debian you need to use the Erlang Solutions PPA if you want Elixir (because you need 17.x), and I believe those packages are only part of the debian packages for R16.
I wanted to know what phoenix.new does that mix new doesn't? Reading the source code of the generator https://github.com/phoenixframework/phoenix/blob/master/lib/mix/tasks/phoenix.new.ex does not help because it simply copies files/folders from a template.
So I have created a repo showing the differences between a mix project and phoenix project through commits.
https://github.com/shankardevy/phoenix-diff
I am not after adding this to doc, as I am not sure how many people will be interested in this trivia. But for someone who is interested, there isn't a place except this. So I'm just posting it here and the issue can be immediately closed.
The URL to the API Docs in the 0.6.2
still links to http://hexdocs.pm/phoenix/0.6.1/
.
Do you need to update that always by hand for every new version?
This boils down to render conn, :index
in addition to render conn, "index.html"
In some cases, such as the resources file, you use html tags. Readme.io won't accept them.
Making an issue so its kept track of.
http://www.phoenixframework.org/v0.10.0/docs/advanced-deployment describes deployment to server by copying a tar file to server, extracting and running the start script. However, it does not give any information about the following
First of all, we should likely ask users to import MyApp.Router.Helpers
instead of always referencing it by full alias. Then, if we have a connection available (which is true in controllers, views, etc), we always pass the connection:
user_path(conn, :index)
The endpoint should only be used in contexts where the connection is not available, like mailers:
user_path(MyApp.Endpoint, :index)
Specifically these:
We should explain configuration options in the /config directory including the use of environment specific config files.
As discussed in IRC, the current website aesthetic is fairly generic and focuses a lot on technologies and not "human" reasons to switch. Compare the phoenix homepage to Ruby on Rails or meteor which focus less on technologies and more on what the framework has to offer developers. "Build apps that are a delight to use, faster than you ever thought possible" (Meteor), "Web development that doesn’t hurt - optimized
for programmer happiness and sustainable productivity" (Rails), compared to "A highly connected web framework" (Phoenix)
Goals for the redesign:
My questions for everyone are:
Note: when I say "switch" that doesn't mean you use it exclusively. It just means you used to use one thing for a given problem and now you use Phoenix in that scenario.
For me, it was the speed and syntax of Elixir and Phoenix. Tests suites ran fast, dependencies installed quickly and the framework itself was ridiculously fast. That wouldn't have been enough though. It also need to have a beautiful syntax and nice APIs. This is the only framework/language combo I've found that covers all those things. So that's what I emphasized in the mockup. I wanted to make it clear that you get blazing fast speed without sacrificing a happy dev environment.
Let me know what you think! Feel free to leave comments. This is very much a WIP. The real version would have real numbers and maybe even a chat with benchmarks along with some example code. I strongly believe that the screencast should also show some benchmarks at the end to make it clear that you're writing beautiful code and getting speed at the same time.
P.S. The content below the blog line is very much a WIP. I'm mostly focus on the header section right now.
We certainly need one.
We should mirror the Phoenix development and treat master
as the unstable docs, and start tagging releases, ie v0.7.x
. I'm always ready to jump to fix different parts of the guides, but then realize we lose context of what is and isn't stable. Going this route will help clear that up.
Originally suggested by @hiphoox on twitter:
It will be great to have a diagram explaining the flow of a request through the apps and processes in Phoenix.
Agreed!
There are a number of selected learning resources in the resources.md file. We could use just a few more in the Phoenix-only category.
There is Chris' talk at ElixirConf and his video on building a chat server. There may be some things we can duplicate from the Elixir wiki, and google knows all, tells all.
Maybe it could be a good idea to write down some kind of a style-guide how to do things in the docs/guide.
As example, while fix some things in the docs I came over a few situations where I wasn't sure about if I should code tag content. Like for keystrokes ctrl-c
or in general for module names like HelloPhoenix
.
We already have a placeholder file for this: D_controllers.md with the barest minimum of an outline. Feel free to work with that or add items as you see fit.
use MyApp.Web, :view
reference: https://gist.github.com/chrismccord/cf51346c6636b5052885
I extracted the output of the tree command from the first page of the guides into this file. Now, I don't think it's really needed.
Thoughts?
We already have a placeholder file with a minimal outline - E_views.md. Feel free to work with that outline or add topics as you see fit.
In the routers file, there is a place where you spelled "controler" instead of "controller"
The link to the markdown file Z_resources.md
appears in several places in the 0_overview.md
file, but never works.
There have been several questions on the mailing list lately about how to test various parts of a Phoenix application. It would be great to have a guide as a reference.
I started the help page when the Phoenix README still required Elixir 0.14.2 and many had already moved on to 0.15.0. That is now stale information and should be deleted.
The question is, do we still need this help page at all? Should we leave it in as "Coming Soon" until we get more data from users on what their pain points are? Something else entirely?
Templates page:
Introduces "structs" to the reader, without defining them, also uses the arcane (to non-elixir users) |> operator. Should perhaps be some sort of callout explaining both of these things.
(obviously, i'm not an elixir expert by any stretch of the imagination, which is probably your target audience :))
This is catch up work from the 0.5.0 release today.
Following your guide, the release executable works fine, but now mix phoenix.start
no longer works because and gives this error:
** (CaseClauseError) no case clause matching: {:error, {:already_started, #PID<0.168.0>}}
(phoenix) lib/phoenix/router.ex:75: Phoenix.Router.start_adapter/2
(phoenix) lib/mix/tasks/phoenix/start.ex:12: Mix.Tasks.Phoenix.Start.run/1
(mix) lib/mix/cli.ex:63: Mix.CLI.run_task/2
(elixir) src/elixir_lexical.erl:17: :elixir_lexical.run/3
(elixir) lib/code.ex:316: Code.require_file/2
Were you seeing this behaviour also?
references:
https://gist.github.com/chrismccord/cf51346c6636b5052885
http://www.phoenixframework.org/v0.10.0/blog
We already have a placeholder file with a minimal outline - F_templates.md. Feel free to work with that outline or add topics as you see fit.
@slogsdon We're steel feeling out the format of the guides, but a simple deployment.md
will work until we're further along. Thanks very much!
The link to API Docs
still points to v0.8.0
should be http://hexdocs.pm/phoenix/0.9.0/
Adding a list of things to update for 0.11 (some of these are still in flux, but this will help us keep a jump on the changes as we get closer to release). I'll update this comment as I come across changes.
[ ] Supervision list has changed https://github.com/lancehalvorsen/phoenix-guides/blob/master/X_mix-tasks.md#ectogenrepo https://github.com/phoenixframework/phoenix/blob/master/priv/templates/new/lib/application_name.ex#L9-L16
To help people find them more quickly. @lancehalvorsen you can still be admin on the repo and etc :)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.