Scaffolding Generator Poll

[Zachary Kessin]

Hi Everyone,

I am working on a bunch of improvements to Chicago Boss with the idea of moving to a 1.0 release in the next few months. There are a number of things I want to do but one of them is to add a scaffolding generator that will create model, controller, templates and some javascript. I want this to integrate with one of the popular Javascript MVC frontends (Backbone, Ember, Angular etc) and would like to know which of those people would find most useful. 

If everyone could take 5 minutes to look at my survey it would be a great help to me

https://www.surveymonkey.com/s/XNLR5JF

--Zach

[Tim McNamara]

-0 on an app scaffold.

Strong -1 on aligning CB to any particular front-end framework.

--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Zachary Kessin]

HI Tim

My plan is that it will be an add on, that will be totally optional,
but will allow those that want to use it skip a bunch of busy work. It
will probably live in its own github repo anyway

--Zach

--
Zach Kessin
Mostly Erlang Podcast
Twitter: @zkessin
Skype: zachkessin

[Nicolas Michel]

Hi,

I definitely agree with that : a core "I know what I do" (ChicagoBoss) layer, with some nice "use me if you want" tools built above.

Both layer must clearly be separated.

Nicolas -

2013/12/18 Zachary Kessin <zke...@gmail.com>

[David Welton]

On Wed, Dec 18, 2013 at 6:49 AM, Tim McNamara <mcnama...@gmail.com> wrote:
> -0 on an app scaffold.

I think a bit of scaffolding could be convenient.

> Strong -1 on aligning CB to any particular front-end framework.

-1 from me too: it's too early to tell which of those things is going
to emerge, and all of them seem fairly opinionated/involved.

That said, I think CB is an excellent backend for the front end JS
frameworks, and it'd certainly be a good investment to make sure it
works with all of them, and perhaps have some convenient, and very
visible add-ons, to make it work with a few popular ones. I'd avoid
'picking winners' as some kind of built-in default at this stage in
the game though.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

[Zachary Kessin]

My plan was to build something to take plugins, so it will generate
for one, but if someone wants another one then it will be pretty easy
to create a plugin to handle it.

That being said I want to make it easy to build an app with one of
them for my own use if nothing else



--Zach

> --
> You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Tim McNamara]

Being able to know to easily plug in a front-end system seamlessly, or close enough to seemlessly, does seem quite neat. I don't know how this could be made modular and flexible, but if that's possible then great. My concern is around producing a bias for any particular framework.

Tim McNamara

@timClicks

[Kai Janson]

I think the idea was just to see "how general" the interface(s) need to be.

--Kai

[Samuel Rose]

Kai and I have started work on common_test based testing. We'll pull
request it when ready. Seemed to us that tests of the framework code
itself were kind of a need.

[Cuong Thai]

Hi all,

According to me, Chicago Boss is good enough. To release v1.0, we need improve performance.

As Zotonic did http://aosabook.org/en/posa/zotonic.html, we have to

+ notice few properties of Erlang VM

+ base on cowboy server

CB will be great!

Regards,

Cuong Th.

[Evgeny M]

All the below is just my opinion

For 1.0 we would need to rewrite routing and reverse routing. At the moment routing is slow as it uses a single gen_server, and somewhere in this gen_server there's ets:tab2list call for every hit. We need either change this to a pool of workers, or just compile (on application start) all routes into an erlang module using erl_parse, erl_scan, compile combined with code:load_binary. The latter is probably the fastest way to do the routing. The reverse routing lacks redirection from standard routes to custom (defined in priv/appname.routes) path. Also there's problem with GET parameters and routes in appname.routes file - if we have {"/foo/", [{controller, "login"}, {action, "login"}]} and return from a controller {redirect, [{controller, "login"}, {action, "login"}, {from, "page"}]} boss will make redirect to /login/login/?from=page instead of /foo/?from=page.

Erlang "share nothing" nature and lots of webserver processes makes memory consumption implode under heavy load.

ErlyDTL - it lacks custom tags which can include content and other tags {% beginfoo %}....{% endfoo %}, there's no nested contexts (see django), there's no access to list and tuple elements with syntax like {{ foo.2 }} and I think {% url %} tag is slow and somewhat hackish. 

We probably need to add render_to_string function and caches which will cache parts of templates. File system cache backend would be useful too. i18n is not optimized for speed on the first sight.

boss_db - good, but lacks some features of django db. Many of such features can't really fit into nosql backends so I'm really not sure if there's a place to change anything without breaking compatibility between backends interfaces. For example often it would be very useful in terms of memory consumption and disk read operations to return only part of attributes of an object as a proplist instead of pmodule, but it would work well only for sql backends. 

models:
I really don't like much how validation_tests and bofire/after_update work together. Often you need to do some complex checks and repeat the same operations in before/after. Another thing is if we have typed fields in model declaration, they are checked before we can to do anything to correct the types.  I'd like to have some standard transformation function which could be run and transform data before type and validation_tests checks, so that we would have all logic related to a model in the same model file.

something like syncdb would be very useful feature.


вторник, 17 декабря 2013 г., 23:36:35 UTC+4 пользователь Zachary Kessin написал:

[Lucas Introne]

very much agreed, with regards to routing, reverse routing, and {% url %} tags.  this has been by far my biggest headache with chicagoboss thus far.

routing between applications (such as when your controller returns redirect to a tuple specifying another app) is still broken, and i haven't written tests in ages, since tests only spin up the current application always choked on pages containing {% url %} tags which route to other applications.  as far as my day-to-day experience with chicagoboss, routing needs the most work.

[somers...@gmail.com]

Hi 

Personally I think the idea of integrating one of the JavaScript frame works would be a great idea - Ive only started using CB but I come from a nodejs background and have been bitten by Meteor in the past 

My preference would be Angular followed next by Backbone though in the next year angularjs will be the dominate front end framework IMO - would it take much work in changing the backend of CB for this purpose I see some areas where this is necessary in particular to templating and may make some of the view redundant in there present form 

Martin 

[Kai Janson]

As it stands right now, it's very easy to use any Javascript frameworks.

I've used AngularJS and Sencha and also jQuery and plain ole Javascript with ChicagoBoss.

No issues, except for the typical JS issues.  But that's not a fault on CB's side.

--Kai