On Wednesday, 30 April 2014 at 09:41:36 UTC, Dicebot wrote:
> On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole wrote:
>>> Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules.
>>>
>>> For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.
>>
>> The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it!
>>
>> Basically my idea is that you register as little as possible. That was why I went with a class for routes.
>>
>> I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.
>
> Why can't stand-alone annotated function be a valid route? Route is pretty much method + url + handler and first two can be inferred by convention in many cases (as done in vibe.web.rest & Co).

The only way I know of that doesn't result in a container is registerRoutes!"mymodule"; Instead of registerRoute!MyRoute;

Now if I could get access to a list of all the modules and hence all routes at CTFE then that wouldn't be an issue. Same deal for models.

Basically give me a way that doesn't impose upon the user to manually register a route and the symbol is available at CTFE, then I'll use it.

I just don't know it.

There is some benefits of having a container for routes however.
Being able to add UDAs to that group of routes. I.e. Don't generate javascript, give them a name/grouping.
While its possible without it, its a bit more distinct.

On 4/30/2014 3:14 AM, Jacob Carlborg wrote:
>
> There's a plugin [1] for Rails for generating a form based on a type. I
> don't understand how anyone can manage without that. It can
> automatically respond in a couple of formats as well. By default JSON,
> XML and Erb template. The most basic example will look something like this:
>

Automatic forms generated from a type are nice for quick-n-dirty stuff, but I find they tend to work against (or at least be much less useful for) the tweaking and customization usually needed in public-facing production sites.

So I started doing it in reverse:

Instead of defining the form in the server-side code and then awkwardly trying to make it generate the HTML I want, I just define the form in HTML. (Or rather, in an HTML template that's still more-or-less valid HTML, with a few additional non-standard tags to help with metadata like "how to validate this field").

Then I use Adam's dom.d (in non-strict mode) to read the HTML form template (preserving the templating stuff), and automatically infer everything I need to automate the form's behavior (and to strip out the non-standard metadata I added).

I've been pretty happy with that so far. It combines the DRY simplicity of "define a form in ONE place and it 'just works'" with the full power and control of hand-written HTML.

What I really need to do is fully de-entange that stuff from my cluttered mess of a homemade web framework <https://github.com/Abscissa/SemiTwistWeb> and release as a separate cleaned-up lib.

On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole wrote:
>> Why can't stand-alone annotated function be a valid route? Route is pretty much method + url + handler and first two can be inferred by convention in many cases (as done in vibe.web.rest & Co).
>
> The only way I know of that doesn't result in a container is registerRoutes!"mymodule"; Instead of registerRoute!MyRoute;

Well you need to specify this only once with root module (usually app.d) supplied as a parameter. You can query all imported modules recursively from it.

> Now if I could get access to a list of all the modules and hence all routes at CTFE then that wouldn't be an issue. Same deal for models.

This can't be done with same guarantees as runtime reflection because of separate compilation. Requirement to transitively to import everything from root module is necessary. I don't see it much of a burden though.

> There is some benefits of having a container for routes however.
> Being able to add UDAs to that group of routes. I.e. Don't generate javascript, give them a name/grouping.
> While its possible without it, its a bit more distinct.

There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.

I think good flexible framework should provide user both options and infer as much as possible by convention.

On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>
> I think good flexible framework should provide user both options and infer as much as possible by convention.

Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.

On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>
>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>
> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.

Sounds like typical use case for imaginary dub plugin system.

On 4/30/2014 1:24 AM, Russel Winder via Digitalmars-d wrote:
>
> I would say from anecdotal observation, so no real significance, that
> most languages end up with a number of frameworks:
>
> 1A. Full stack Web framework.
> 1B. Lightweight HTTP framework.
> 2A. Full feature networking framework.
> 2B. Lightweight networking framework.
>
> In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have
> Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B
> asyncio (showing my Python bias here :-)
>

That does seem to happen.

FWIW, IMO the big selling point of D is it's fairly unique knack for letting you eat your cake and still have it. I rather like to think we can manage merging the "full stacks" with the "lightweights".

On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
> On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
>> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>>
>>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>>
>> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
>
> Sounds like typical use case for imaginary dub plugin system.

Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.

On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole wrote:
> On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
>> On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
>>> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>>>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>>>
>>>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>>>
>>> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
>>
>> Sounds like typical use case for imaginary dub plugin system.
>
> Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.

There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place.

On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
> On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole wrote:
>> On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
>>> On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
>>>> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>>>>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>>>>
>>>>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>>>>
>>>> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
>>>
>>> Sounds like typical use case for imaginary dub plugin system.
>>
>> Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.
>
> There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place.

The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'.

Hmm now if only I understand assembly better. And was able to write a JIT then maybe. Maybe then I could implement my evil ideas.

On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
> This is the stuff marketing campaigns are made from.

Eh, like Jacob said later, I don't think this is a totally fair comparison cuz I'm a world class D expert but a RoR n00b, so there's naturally some difference in speed there.

Of course, I doubt the gap will ever be closed, since Ruby's awfulness isn't dependent on my experience level. It's not like it will ever get static typing even if I used it all the time. It won't get faster. ActiveRecord won't get sane.

But still, one person's productivity is too subjective to focus a lot on IMO.