On Wed, 30 Apr 2014 17:17:01 +0000, Ola Fosheim Grøstad wrote:

> 4. server unwraps the data and blindly inserts it into the database

ummmm...... wtf?  This is why hackers keep stealing my credit card....

Client side validation should only be used for giving users immediate fed back and saving cycles. You do know I can look at your js, find all of your ajax calls and send what ever data I want right..

On Wed, 2014-04-30 at 05:00 +0000, via Digitalmars-d wrote: […]
> Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.

I disagree. A good Python Web application would be using Flask, Bottle, Tornado, Pyramid, Django as a framework and a design and idioms to suit. A good Go Web application has a very different architecture, design and code idioms due to the use of CSP via the goroutines. I do non-HTTP networking rather than HTTP networking and end up with very different solutions to the same problem using Python and Go. If QtD were in a better state I could do a D version…

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 30 April 2014 at 17:23:39 UTC, Byron wrote:
> Client side validation should only be used for giving users immediate fed
> back and saving cycles. You do know I can look at your js, find all of
> your ajax calls and send what ever data I want right..

If the security model depends on code being hidden then there is something very wrong with it.

The database should do all the veracity checks and apply all the consistency constraints. The server should merely prepare the data. If any constraints triggers the transaction is rolled back.

This becomes even more important when you have multiple servers and versions of the server software maintained by various divisions writing to the same database.

On Wednesday, 30 April 2014 at 17:23:49 UTC, Russel Winder via Digitalmars-d wrote:
> Tornado, Pyramid, Django as a framework and a design and idioms

I've looked closely at Django. I find it more convenient to use smaller independent libraries inspired by Django than using the framework itself.

The problem with frameworks that are supposed to support a plugin architecture is that they become complex and not very transparent. That makes debugging harder, and you need to debug because plugins don't always integrate well with each other. So at the end of the day you spend time struggling with debugging complex mechanics that you only need to support plugins. With a more nimble environment you spend less time debugging (or trying to figure out what a plugin actually does) and more time coding stuff that fits the requirements.

Frameworks requires you to invest time, that can pay off, but frameworks have trouble moving with the times so… that investment does not pay off long term when you realize that you need to switch to a different framework.

As an example: some of the frameworks I've looked at predated UTF-8 and contains an insane amount of code just for dealing with different character sets. The same is true for the client side. Some of the javascript frameworks contains a silly amount of code for dealing with IE6 and other browsers that you can safely ignore…

> A good Go Web application has a very different architecture, design and code idioms due to the use of CSP via the goroutines.

Well, I only know Go from Google App Engine. Browse the hello-world tutorial and you'll see that the Python version is more legible (?):

https://developers.google.com/appengine/docs/go/gettingstarted/introduction

https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction

On 2014-04-30 15:38, Adam D. Ruppe wrote:

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

Ruby has gotten faster in each release.

-- 
/Jacob Carlborg

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? BTW, I would probably use the "unittest" keyword for other kinds of tests than unit tests as well.

-- 
/Jacob Carlborg

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

> BTW, I would probably use the "unittest" keyword for other kinds of tests than unit tests as well.

This is main problem with your expectations I think.

On 2014-04-30 17:04, Adam D. Ruppe wrote:

> I like implementing things myself :P
>
> That's the question I dread most at meetings now: "is there a gem for
> this?" idk, in the time it takes to search for and evaluate third party
> code, I could have just written it myself. Especially since libraries
> almost always need some kind of customization for our specific case anyway!

I don't agree with this.

> A big difference though is the compiler helps you a lot in D. In Ruby,
> for example, the main reason we use the unit tests (so far) is to help
> ensure consistency after refactoring something. It catchings things like
> a renaming we missed, or a removed method still in use.

Then you're not using unit tests correctly ;)

> In D, you just recompile and those things are found almost instantly
> without needing to actually run any code.

Yeah, sometimes it would be nice with static typing.

> They deliberately avoid the most important parts of a relational database:
>
> http://guides.rubyonrails.org/migrations.html
>
> "The Active Record way claims that intelligence belongs in your models,
> not in the database. As such, features such as triggers or foreign key
> constraints, which push some of that intelligence back into the
> database, are not heavily used."

I don't really agree with that. Although I'm not a fan of store procedures/functions in the database. But I don't mind foreign key constraints. We used that at my previous work. Via a gem :)

> ORM is something I only like in very small quantities, but ActiveRecord
> uses it for *everything*, well, except for the things it doesn't even
> support.
>
> The problem here is one of encapsulation and of correctness. If
> something bypasses the model - which is required for tasks the library
> doesn't even support and also likely to happen if there's a second app
> using the data - all kinds of stuff can get in there that is bad.
>
> You also have problems like race conditions:
>
> account = BankAccount.find(1)
> account.balance -= 10
> account.save!

I think most Rails application are run single threaded. But with multiple processes instead.

> What if two of those run concurrently? I searched the web quickly for
> this and haven't found a good answer yet...
>
> Then, with referential integrity, the docs suggest DIY or getting some
> third party gem, because their godawful library doesn't really support
> it. The best it does is offer you a square wheel with the dependent
> thing. Stupid stupid stupid.

All libraries have positive and negative sides.

> idk, I use my database.d which has a little bit of overlap with what
> active record does, but since I generally see ORM as being a nasty
> anti-pattern and horribly leaky abstraction, I didn't go far with it.

Using a random D module for this doesn't feel very comfortable, no offense. No documentation, no way to find examples and so on.

> There's really nothing to fear with writing SQL, except the cases where
> the language sucks.

ActiveRecord will hide all the ugliness of SQL. Properly escape values, to type conversions, time zone conversions and so on. It's also database independent.

> (UPDATE and INSERT being so different, and the
> solutions being different for the various vendors, ugh. That's why I
> made my DataObject, it gathers the changes together then issues one of
> those commands. It can also be gotten from a query, making it a kind of
> simple active record:
>
> auto obj = mysql.queryDataObject("select * from foo limit 1").front;
> obj.whatever = "something";
> obj.commitChanges(); // calls UPDATE foo SET whatever='something' WHERE
> id = ?
>
> which also works on joined queries on MySQL btw and offers easy support
> for multiple primary keys or ones not named "id" (as an argument to
> commitChanges), something active record as far as i can tell doesn't
> even try to do, but it doesn't try to fetch child objects or anything
> like that.
>
> I have considered adding child object fetching, but I don't really see
> the need, it is easy to write a method that does that if you want to.)
>
>> I prefer HAML (similar to Jade in vibe.d) but I don't think it's that
>> bad. What do you use?
>
> The ruby thing looks like this <span class="foo"><%= @some_value %></span>.
>
> For my D stuff, I have two options:
>
> 1) create the HTML right in D using dom.d. I like to use this for
> objects that know how to format themselves and output strictly semantic
> XML/HTML. The visual styling is then done with CSS. This works better
> than you might expect!

Are you using some kind of proxy for this or are you pushing back the view layer to the model?

> 2) web.d also has a fairly simple replacement system too:
>
> <span class="foo">{$some_value}</span>
>
> it also supports inserting partials
>
> <div html-from="{$dynamic_html}"></div> or <include partial="foo" />,
> though the include thing takes a wee bit of helper code from the app
> because it needs to find the html somewhere.

Well, that's the same as in Rails. The HAML version would be:

<div html-from="#{@dynamic_html}"></div> or = render "foo". In Rails the partial is just a template prefixed with an underscore. It fill find it relative to the controller's view directory.

> And the variable replacement can be piped: {$some_count|plural user
> users} for example, which is kinda cool.

I'm not sure I understand this piping.

> It does NOT support intertwined code. Other things are done with
> attributes, such as class="if-logged-in" or <ul from="data_thing" />
> (infinitely extensible with the server-side DOM).

What do you mean with "intertwined code"?

> It looks like this
>
>    root "home#index"
>
>    get "/users/login", to: "users#login"
>
>    namespace :admin do
>      resources :users do
>        resources :children
>      end
>    end
>
>
> and so on. It isn't awful (especially now that I get what they mean by
> "resources"), but my web.d rarely uses explicit routing at all, it
> figures it out automatically by the names, protection level, and types
> of child members.

In Rails that would be:

match ":controller(/:action(/:id))"

So "/foo/bar/1" would route to "bar" action in the FooController with "1" assigned as the "id" parameter in "params". Only works with public methods. I really hate this. It quickly becomes a big mess.

You can also do a catch all route:

match "*path" => "home#page_not_found"

> Responding with json, xml, and html Just Work with web.d, it figures it
> out from the static type of the function return value.

In my experience it's rarely so easy. Most of the time I need to do some customization of the format anyway so the built-in formatting isn't suitable.

> Yes, obviously that's some of it, but there's other things that I don't
> expect to change, especially things like runtime errors for what the D
> compiler would catch.

Yes, sure.

> i love that, different strokes i guess.

I don't mind it but sometimes I just want to get some work done. I mean, I've started out (or planed to) with some project in D but then I needed to create all the support libraries and tools so I've almost forgot what I was going to do in the first place.

I want to use Sass, CoffeeScript and HAML. But I don't want to write three compilers just to do some web development.

-- 
/Jacob Carlborg

On Wed, 2014-04-30 at 18:04 +0000, via Digitalmars-d wrote: […]
> I've looked closely at Django. I find it more convenient to use smaller independent libraries inspired by Django than using the framework itself.

If you have a "full stack" solution to a problem then Django does work quite well, however most of my use is far from "full stack" so Flask, Bottle, Twisted and Tornado are my "go to" (*) Python frameworks

> The problem with frameworks that are supposed to support a plugin architecture is that they become complex and not very transparent. That makes debugging harder, and you need to debug because plugins don't always integrate well with each other. So at the end of the day you spend time struggling with debugging complex mechanics that you only need to support plugins. With a more nimble environment you spend less time debugging (or trying to figure out what a plugin actually does) and more time coding stuff that fits the requirements.

For "lightweight" problems, "full stack" frameworks are a disaster. Hence the "lightweight" frameworks. Flask + SQLAlchemy is a very popular combination. I'm not sure what the D equivalent is but I guess it is vibe.d + ???.

[…]
> Well, I only know Go from Google App Engine. Browse the hello-world tutorial and you'll see that the Python version is more legible (?):

I treat GAE as an anti-pattern.



(*) Are we allowed to have gotos any more since Dijkstra's letter?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 30 April 2014 at 16:02:25 UTC, Nick Sabalausky wrote:
> Well, I've been using mustache-d as my main templating engine, which is just a general text preprocessor (Although I'm kinda eyeing that other text preprocessor that uses actual D code).

ah, I see. BTW, fun fact: dom.d can understand ASP and PHP style tags. You need to set a special callback or call enableAddingSpecialTagsToDom() before parse,  (The latter will also enable storing comments, <! stuff> and <?stuff>) but then it will work.

I did that to enable dual-use templates that have some PHP code too. But it might be interesting to use for template stuff too...

BTW (ok this whole post is turning out to be a series of BTWs), web.d also has a template function that is dom-aware which I think is potentially very interesting.

Like it could see <span>{$foo}</span> and be aware to add a class to that span or something. Or it could automatically wrap variables in spans iff that makes sense in the html context.

Stuff I've never really used despite writing this some time ago... but I still think there's some potential to all this.


> Granted there are still things I have to refrain from doing in my HTML form templates because it would violate well-formedness *too much* even for an ultra-relaxed HTML DOM. But those cases always have other (arguably more sanitary) ways to accomplish the same thing.

yea