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).
