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.
On Thursday, December 26, 2013 8:23:21 PM UTC+5:30, Evgeny M wrote:
>
> 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
> написал:
>>
>> 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
>>
>
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
