D For A Web Developer
Jacob Carlborg via Digitalmars-d
digitalmars-d at puremagic.com
Wed Apr 30 12:53:53 PDT 2014
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
More information about the Digitalmars-d
mailing list