3 ms·

Quote interesting release, many useful features. `action_fallback` looks really nice. Contexts ... not so much imo

ch4s3 9y ago
Contexts are in practice pretty nice, and you don't have to use them. I've found that in my own work with 1.3.rc.*, the contexts describe an area of the system and help enforce some separation of concerns. That said, you're free to build everything in one context.
the_angry_angel 9y ago
> Contexts ... not so much imo I'll prefix my comment by saying I'm someone who is more on the sysadmin side of the scale of things. My code isn't pretty, but it generally works well enough to get the job done. I'm learning (probably the most important thing, I guess). Contexts are one of things that I felt the same about. Until I tried really using them, rather than stressing over whether or not I was using them properly. I made the mistake of trying to think of them as microservices, which bogged me down and for my purposes was complete overkill. I've now reached a kind of happy medium, which I've realised that I really should have already been using. I've kinda realised I suck at api design. And for that I'm very thankful to the phoenix team, because it feels like I'm learning.
fredsir 9y ago
Contexts might not like nice, but they really are in practice.
kureikain 9y ago
I have an example where context works well for me. I have built an app[0], the app allow user to submit links, either using our web ui or via a bot. When using web ui, they have to login, hence we associate the links with that user. The bot is different, everyone submit via the post share the same `Bot` account. In other words, the process of inserting a link from web ui or via bot is a bit different. Without context, I would use different module or some branch code to distinct between them. I think context solves that nicely for me. --- [0] https://one.betterdev.link https://one.betterdev.link which is an extra version of https://betterdev.link/ https://betterdev.link/
bratsche 9y ago
I love contexts! But if you don't, that's cool too. There are mix tasks for using the older style generators and mix tasks for the newer context style generators. Use whichever you prefer.
lojack 9y ago
Contexts are just the default now. Nothing is preventing you from doing things the old way, or from using them in 1.2 without upgrading. If you can think of a better architecture that doesn't involve contexts, then that should absolutely be what you're doing.

Contexts are in practice pretty nice, and you don't have to use them. I've found that in my own work with 1.3.rc.*, the contexts describe an area of the system and help enforce some separation of concerns. That said, you're free to build everything in one context.

the_angry_angel 9y ago

> Contexts ... not so much imo I'll prefix my comment by saying I'm someone who is more on the sysadmin side of the scale of things. My code isn't pretty, but it generally works well enough to get the job done. I'm learning (probably the most important thing, I guess). Contexts are one of things that I felt the same about. Until I tried really using them, rather than stressing over whether or not I was using them properly. I made the mistake of trying to think of them as microservices, which bogged me down and for my purposes was complete overkill. I've now reached a kind of happy medium, which I've realised that I really should have already been using. I've kinda realised I suck at api design. And for that I'm very thankful to the phoenix team, because it feels like I'm learning.

fredsir 9y ago

Contexts might not like nice, but they really are in practice.

kureikain 9y ago

I have an example where context works well for me. I have built an app[0], the app allow user to submit links, either using our web ui or via a bot. When using web ui, they have to login, hence we associate the links with that user. The bot is different, everyone submit via the post share the same `Bot` account. In other words, the process of inserting a link from web ui or via bot is a bit different. Without context, I would use different module or some branch code to distinct between them. I think context solves that nicely for me. --- [0] https://one.betterdev.link https://one.betterdev.link which is an extra version of https://betterdev.link/ https://betterdev.link/

bratsche 9y ago

I love contexts! But if you don't, that's cool too. There are mix tasks for using the older style generators and mix tasks for the newer context style generators. Use whichever you prefer.

lojack 9y ago

Contexts are just the default now. Nothing is preventing you from doing things the old way, or from using them in 1.2 without upgrading. If you can think of a better architecture that doesn't involve contexts, then that should absolutely be what you're doing.