D For A Web Developer

[via Digitalmars-d]

On Wednesday, 30 April 2014 at 17:17:02 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky 
> wrote:
>> Sounds pretty much exactly what I'd expect from just about any 
>> PHP-based application. :/
>
> Modern PHP isn't so bad. I can write acceptable code in PHP. 
> Though, I only do so when there is no other option, since it is 
> the least desirable option next to Perl. The good thing about 
> PHP is that default installs tend to have good C libraries. I 
> think it would have died without that.
>
> So, if PHP is ok then it must be the PHP programmers that are 
> to blame. I shudder to think what happens with a niche 
> community if they pick it as the next fad… It could destroy any 
> upcoming programming community with spaghetti-hell. Are you 
> sure you want to market D as a web platform?
>

This hasn't happened to Ruby (or Rails for that matter), which is 
definitely marketed as a web platform. Most of the Ruby code that 
I've seen is of exceptionally high quality. That's true not only 
regarding the code itself, but also for the interfaces it 
provides (in the case of libraries), which are usually well 
thought out. For PHP, on the other hand...

I believe this has a lot to do with the language. Apparently it's 
harder to write bad code in some languages than in others.

>> familiarity with the other stuff than I do. Ugh, but SQL can 
>> be such a pain, especially with all the vendor differences, 
>> and when compared to accomplishing something in whatever 
>> language I'm invoking SQL from.
>
> You can implement it in the ORB or wherever unit that provides 
> transactions. I was more pointing to what I find useful 
> conceptually in terms of layers:
>
> 1. user input on the client
> 2. validate on client
> 3. post using ajax
> 4. server unwraps the data and blindly inserts it into the 
> database
> 5. if transaction fails, notify client, goto 1
> 6. done.

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

I've created a gem that does almost all of that transparently. I 
just need to mark the form with "remote: true", and adhere to a 
few simple naming conventions (which Rails' form generators do 
automatically).