On Thursday, 1 May 2014 at 12:17:56 UTC, Ary Borenszweig wrote:
> On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
>> On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
>>
>>> This cannot be a good idea. If the block says unittest then it contains
>>> unit tests, not integration tests or system tests, just unit tests.
>>
>> Then we need to come up with a separate framework for doing all other
>> kinds of tests.
>>
>
> Yes. And then you need two different commands to check if the system works. And if you want, for example, coverage analysis I wonder how you'd do that... That can't be good.

Two commands effectively. `rdmd -unittest` for development cycle of single module and `make test` to verify everything after feature/bugfix is completed. This is what I tend to do with existing tools (by splitting higher level tests in separate applications), adding some in-language support will just make intention a bit more clear.

On 5/1/14, 3:50 AM, John Colvin wrote:
> On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
>> On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
>>> On 2014-04-30 11:43, Dicebot wrote:
>>>
>>>> This is common complaint I still fail to understand. I have never ever
>>>> wanted to run a single unit test, why would one need it? If running all
>>>> module tests at once creates problems than either module is too big or
>>>> unit tests are not really unit tests.
>>>
>>> Why would I run more tests than I have to?
>>
>> Because you hardly notice difference between 0.1 and 0.5 seconds
>
> The compilation time is often more of a problem than the runtime.

That's the case for phobos. -- Andrei

On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
>
> IMO the client shouldn't do any validation, unless you can really, really trust it. That's why I like to do things the following way:
>
> 1. user input on the client
> 2. post using ajax
> 3. server validates and stores the data
> 4a. if transaction or data is invalid fails, send errors to the client
> 4b. if everything's ok, tell the client to redirect to the next page
> 5. on the client, add error CSS classes to the relevant fields, or execute the redirect
>

That's a lot of unnecessary back and forth to the server for a
JS-based design. Plus it avoids some of the nicer UX enhancements
JS can enable, like validate-as-you-type, and does so without the
benefit of not requiring JS. Kind of a worst of both worlds (no
offence).

Naturally, the server needs to do validation no matter what. But
there's nothing wrong with doing an optional preliminary
validation on the client side first.

On Thursday, 1 May 2014 at 15:11:07 UTC, Nick Sabalausky wrote:
> On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
>>
>> IMO the client shouldn't do any validation, unless you can really, really trust it. That's why I like to do things the following way:
>>
>> 1. user input on the client
>> 2. post using ajax
>> 3. server validates and stores the data
>> 4a. if transaction or data is invalid fails, send errors to the client
>> 4b. if everything's ok, tell the client to redirect to the next page
>> 5. on the client, add error CSS classes to the relevant fields, or execute the redirect
>>
>
> That's a lot of unnecessary back and forth to the server for a
> JS-based design. Plus it avoids some of the nicer UX enhancements
> JS can enable, like validate-as-you-type, and does so without the
> benefit of not requiring JS. Kind of a worst of both worlds (no
> offence).

Well, naturally I disagree :-)

It's exactly two requests to the server, same as for a normal form submission without JS:
- one for the actual submission
  => server responds either with the errors, or with a redirect URL
- and another one for requesting the next page (only if everything was ok)

Technically, you could already send the contents of the new page with the server response, but this has several drawbacks (doesn't change the URL, double POST on reload, etc.), so a redirect is pretty much standard.

I don't see how you could improve on that in respect to the number of requests...

It also degrades gracefully if JS is not enabled: In this case, the form submission will not be intercepted by the JS and therefore won't be turned into an AJAX request. The server notices that it's not an XHR request, and automatically responds by rerendering the form view with all the CSS classes and error messages in place. (This requires a bit more work on the server side, but not a lot.)

>
> Naturally, the server needs to do validation no matter what. But
> there's nothing wrong with doing an optional preliminary
> validation on the client side first.

Exactly. I just feel that client-side validation is unnecessary duplication in most cases. But sure, it can be used where it makes sense.

On 2014-05-01 15:54, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:
>
>      Post.includes(:comments).where(comments: {title: "bar"})
>
> (It also eager-loads the comments, but this is usually desired anyway,
> because an OUTER JOIN doesn't make sense if you're not going to use the
> joined records.)

The SQL code "includes" generates is unspecified. Sometimes it can do an extra "select" instead of a "join".

-- 
/Jacob Carlborg

On 2014-05-01 19:56, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> Exactly. I just feel that client-side validation is unnecessary
> duplication in most cases. But sure, it can be used where it makes sense.

There's a gem [1] for that. Although it seems that one is not maintained anymore.

[1] https://github.com/DockYard/client_side_validations-simple_form

-- 
/Jacob Carlborg

On Thursday, 1 May 2014 at 18:35:40 UTC, Jacob Carlborg wrote:
> On 2014-05-01 15:54, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>
>> You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:
>>
>>     Post.includes(:comments).where(comments: {title: "bar"})
>>
>> (It also eager-loads the comments, but this is usually desired anyway,
>> because an OUTER JOIN doesn't make sense if you're not going to use the
>> joined records.)
>
> The SQL code "includes" generates is unspecified. Sometimes it can do an extra "select" instead of a "join".

You're probably right. I thought that changed in a recent release, but can't find it anymore.

On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
> IMO the client shouldn't do any validation, unless you can really, really trust it.

Client side validation is about better feedback. Today's browsers are fast enough for doing field validation for every keystroke.

> 4a. if transaction or data is invalid fails, send errors to the client

Without client side validation you need more detailed errors from the server.

On 01/05/14 21:55, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> You're probably right. I thought that changed in a recent release, but
> can't find it anymore.

I don't know. I wouldn't trust it. It's the behavior in Rails 3. I haven't used Rails 4 yet.

-- 
/Jacob Carlborg

On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:

> I think one of the great things about Rails and Ruby is all the libraries and plugins that are available. If I want to do something, in RoR there's a big chance there's already a library for that. In D, there's a big chance I need to implement it myself.

this has been the fundamental issue for me. its not just missing libs, its libs that are surfaced via a C-binding, which in my limited experience have been difficult to use and make portability hard.

I think D is a superior language to Go, but Go has a very complete SDK and its all written in Go, so I don't have to worry about chasing down native libs to install.

brad