dgamidov

dgamidov

Thanks for information!

1
Post #21
josevalim

josevalim

Creator of Elixir

Try this. Create a new project with mix new hello and then change the mix.exs file to do the following:

defp deps do
   [{:phoenix, "~> 1.3.0-rc"},]
end

Can Hex fetch Phoenix? If it cannot, it is an issue with your Hex installation. Or it cannot find Phoenix or it cannot update the registry metadata. If so, try deleting any *.ets or *.ets.gz files in ~/.hex.

2
Post #22
rafal-radziszewski

rafal-radziszewski

What was the motivation behind changing directory structure? The one with main modules nested in lib and other modules in the same named folders seemed really reasonable - it was quite natural split between high level API and implementation details. It is also convention used in every library in the language and I believe would make it easier to eventually split app into separate OTP apps as needed.

Besides that - great direction! I really like how Phoenix emphasizes its use case and does not want to be all-in package - it always bothered me with Rails.

6
Post #23
Ljzn

Ljzn

Thank you!
It seems to be caused by the hex mirror. After removing mirror_url https://cdn.jsdelivr.net/hex in hex.config, everything goes well.

2
Post #24
PatNowak

PatNowak

Thanks @chrismccord for this! It’s awesome. When I digged into Phoenix few months ago I saw it uses some parts of DDD eg. isolated repo to orchestrate the models, but now it’s all right. Bounded Contexts are another needed level of abstraction, so controller doesn’t look like “I’m the boss and I force repo to do anything for me”, but he deals with BCs. Also changing the structure is very nice.

Does the live reload now apply for /lib/myapp/web/*? I guess it is. Also I like generators using phx and your effort that we should think more about the code and how we gonna use it and less about generating CRUDs and wondering how to modify them :slight_smile:

3
Post #25
michalmuskala

michalmuskala

To clarify - ecto repo is not a repository pattern. It differs in some key areas, most notably repository pattern calls for a repo per entity you’re going to query - ecto has just one repo that is used to explicitly represent the database in the code - one for all entities.

Neither phoenix’s contexts are bounded contexts per DDD on their own - you can use them as such, but there’s nothing that requires it. I’m sure it was an inspiration, but I’m also pretty sure the phoenix team does not want to enforce DDD on everybody.

3
Post #26
PatNowak

PatNowak

Yeah, but I don’t follow DDD as it is. I just like that’s what’s most important and usable is in Phoenix as it should be. Using BCs is concise, clear and will make controllers way more thin :slight_smile:

Also action_fallback is great here and using with clause.

1
Post #27
aptinio

aptinio

I too am used to the convention where my_context.ex and my_context/ are in the same directory. The module names MyContext and MyContext.MySchema are also consistent with the former structure.

3
Post #28
kostonstyle

kostonstyle

Is there anyway to prevent ecto? Earlier was --no-ecto.

Thanks

1
Post #29
chrismccord

chrismccord OP

Creator of Phoenix

yes, same flag, mix phx.new my_app --no-ecto

1
Post #30