Hi, David and I discussed this today and we think that there is a possibility to make a zotonic-plug in combination with a “default” site in Zotonic.
David made some notes, which I assume he will share here :) There are some details we need to figure out, like how we are using cowboy2 and if we might want to use ecto. Cheers, Marc Sent from my iPhone > On 10 Oct 2017, at 15:24, Allen Wyma <[email protected]> wrote: > > I'm more than happy to help convert some pieces. I left some messages on > gitter. I just couldn't get zotonic to run by itself. It would be great if > there was a way I could just add them as plugs, like David was saying. > > On Tuesday, October 10, 2017 at 8:21:05 PM UTC+8, [email protected] wrote: >> >>> I have converted larger Erlang codebases to Elixir incrementally >> >> Jake, can you explain the rationale behind this? Why did you want to run >> your apps in Elixir instead of Erlang? >> >>> The most interesting thing is probably an example combining Zotonic with >>> Phoenix. >> >> This is something I’ve been thinking about for a while now. Going one step >> further: what about porting Zotonic to Elixir? There are a many reasons why >> Zotonic and Phoenix (= Photonic ;) are a great match: >> >> 1. As of yet, there’s no fully-fledged CMS available for Phoenix/Elixir. >> Having a stable CMS for Phoenix will enable developers to be more productive >> in Elixir and attract more of them to start doing Elixir in the first place. >> There’s definitely a demand for a Phoenix CMS: as Allen and others write in >> this thread and again others have told me. >> >> 2. This is also a great chance for Zotonic. As most web developers on the >> Beam VM are doing Elixir, it will be much easier for them to submit >> improvements to an Elixir CMS than an Erlang one. So by porting Zotonic to >> Elixir we will hopefully find more contributors. >> >> 3. The number of Zotonic contributors is rather small for such a large >> product. One way to solve this problem is by reducing the scope of Zotonic. >> Currently it has custom logic for HTTP (Cowmachine), templates (template >> compiler), routes (dispatch compiler) and so on. All these belong to web >> applications in general, not a CMS specifically. Let’s use Phoenix to take >> care of these. Phoenix has a (much) larger community, so it can do these >> fundamentals better and more efficiently than we can. Worst case, we would >> have to build something on top of what Phoenix ships with out of the box, >> such as adding adding dynamic routing. Let’s stick to what makes Zotonic >> unique: its flexible datamodel, performant depcache, (possibly) ErlyDTL >> template language. >> (As a side-note, let’s not forget Zotonic is much older than Phoenix, and >> Zotonic has been doing things such as real-time client/server communication >> before Phoenix existed, let alone added Channels.) >> >> 4. Phoenix is well-designed and properly decoupled (Plug for HTTP, Ecto for >> databases and Contexts for domain logic). The same cannot not always be said >> of Zotonic. So switching over to Phoenix will result in smaller Zotonic >> components written in higher-quality code. >> >> 5. Most web development on the Beam VM is happening in Elixir: if you need >> authentication, JSON-LD parsing etc., there are much more likely to be >> up-to-date, well-maintained and documented Elixir packages available on >> Hex.pm than a single Erlang one. It therefore makes sense to integrate with >> the Elixir ecosystem. >> >> Cheers, >> >> David >> >> >> Op dinsdag 3 oktober 2017 04:23:11 UTC+2 schreef Jake Morrison: >>> >>> On Mon, Oct 02, 2017 at 10:39:04AM +0000, Marc Worrell wrote: >>> > >>> > > On 2 Oct 2017, at 02:19, Jake Morrison <[email protected]> wrote: >>> > > >>> > > Marc, >>> > > >>> > > On Fri, Sep 29, 2017 at 09:40:07AM +0000, Marc Worrell wrote: >>> > >> Can mix build rebar3 based apps? >>> > > >>> > > Mix is more or less a replacement for rebar3, so they are mutually >>> > > exclusive, though largely compatible. >>> > > >>> > >> If so then we can just provide a mix based project. >>> > > >>> > > For Elixir users, the easiest thing is if Zotonic can be used >>> > > as a library which can be pulled in by mix/rebar from https://hex.pm/, >>> > > i.e. it's a well behaved OTP application. It might make sense >>> > > to have some mix tasks which e.g. create template modules. >>> > >>> > The master is being split in OTP apps, with the specific goal of >>> > being reusable. >>> > >>> > Actually, there is not much left in the ‘zotonic.app’, almost everything >>> > is moved to the other (OTP) apps. >>> > >>> > So I guess having a Mix (/Elixir) project that people can clone could >>> > be a good starting point for Elixir devs. >>> >>> The most interesting thing is probably an example combining Zotonic with >>> Phoenix. >>> >>> > >> I am also thinking of using the introspection (we are using that for >>> > >> notify observers) to discover if a module, filter, action or other >>> > >> type of Zotonic callback module is an Elixir module. >>> > >> And if so we could generate or use some glue code to call directly >>> > >> into the Elixir modules from Zotonic. >>> > > >>> > > Generally speaking, Elixir code is functionally the same as Erlang >>> > > code, the module atoms just start with 'Elixir.', so that may not be >>> > > necessary. >>> > >>> > So if an Elixir source file defines the Elixir equivalent of a function: >>> > >>> > observe_some_event/2 >>> > >>> > Then in the function definitions I can find just that function? >>> > And the module itself would be loaded as ElixitSomModuleName? >>> > >>> > That would make it quite straightforward to integrate Elixir code >>> > into the notification system. >>> >>> It's basically the same, just the Elixir compiler adds "Elixir" to >>> the front of the module names. So probably nothing needs to be done. >>> >>> In Erlang, if you have a module foo, it would look like: >>> >>> -module(foo). >>> >>> -export([observe_some_event/2]). >>> >>> observe_some_event(One, Two) -> ... >>> >>> And you would call it like foo:observe_some_event(One, Two) >>> >>> In Elixir, it would look like: >>> >>> defmodule Foo do >>> def observe_some_event(one, two) do >>> ... >>> end >>> end >>> >>> From Erlang, the module atom would be 'Elixir.Foo', and you can call it >>> like 'Elixir.Foo':observe_some_event(One, Two) or apply('Elixir.Foo', >>> observe_some_event, [One, Two]) >>> >>> > - M >>> >>> Jake > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Zotonic developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "Zotonic developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
