On 2011-05-15 19:15, Adam D. Ruppe wrote:
Jacob Carlborg wrote:
But that way you would need to declare different types of Options
structs all over the place?
Sometimes, but most functions are fine with regular argument lists,
to me, using enums for options where appropriate.
In Rails basically every view helper function takes two hashes of
options, one related to the function and one for html attributes.
I think there are other languages available that is far better than
PHP that you could compare with instead. Ruby on Rails:
Come to think to fit, PHP's $_REQUEST() would have worked here too
and shaved off a couple lines.
Anyway, I've used Ruby before, but never Rails. The to_i and to_s
things are familiar.. me forgetting to write them caused many
problems in that project. I hate dynamic languages so much. That
Ruby project is what put the nail in the coffin.
I want to get an idea of how Rails works though, so see how well
my approaches stack up. But, aside from discussions like this one,
I haven't had a chance to get into it.
I think you really should give it a try. This is a good place to start:
http://guides.rubyonrails.org/
This will try to find a Post with the given id and automatically
converted the given value to an integer.
This is similar to how my database libs work. It actually lets
the database do the conversion though.
I don't know if it's rails or the database that does the conversion.
I've been thinking for a while to try and create something
similar as Rails' ActiveRecrod for D but every time I tried to do
it turns out to work quite badly with a static type system.
Have you seen Piotr Szturmaj's Postgres code?
http://www.digitalmars.com/d/archives/digitalmars/D/learn/D2_postgresql_interface_-_Phobos2_23693.html#N23695
(there's more posts than that on it too if you search)
It might give you some ideas.
I probably have seen that post but since you have to manually specify
the columns in a table I didn't like it.
I went the other way; I don't mind writing SQL. (I always find
automatic mappings the other way to be inefficient and lacking
anyway.)
I really like how it works in Rails.
As I said above, I don't see the big advantage if I have to use
Variants all over the place .
The thing is it's not *all* over the place. There's a small area
where you use them, and you get the static type benefits everywhere
else.
Even with the variant areas, the static type system helps a little
bit. At least misspelled variable names are caught ahead of time by
the compiler.
I guess you're right.
HAML, generates HTML - http://haml-lang.com/
Syntax and indenting aside, concepturally, that's similar to
how my DOM based code works.
auto profile = holder.addChild("div").className("profile");
auto left = profile.addChild("div").className("left column");
left.addChild("div", print_date).id("date");
left.addChild("div", current_user.address).id("address");
Don't know why but I think this is verbose and it's more difficult to
visualize how the HTML will look like.
One big difference, semantically, is my code always escapes HTML
by default. Looks like haml uses&= for escaping, while = does
not.... so their homepage example is both incorrect and
open to XSS attacks!
That depends on how it's configured. In addition to that Rails provides
functions for escaping.
(I offer two ways to write HTML: some functions take arguments
of type Html, like Table.appendRow:
table.appendRow(" ", Html(" "));
First column appears as literally . Second column shows up
as a non breaking space.
But, mostly, if you want to mess with html, you use the innerHTML
property. It's a pain to use because outputting HTML is, 9 times
out of 10, wrong. Any template system that doesn't do this gets
a big point against it in my book, similarly to any database
library that makes mixing unescaped text in the easiest way...)
Anyway, their syntax is certainly brief. I can see the appeal in
that.
Curious though, how does haml handle forms? Looking through the
documentation, it doesn't seem to at all.
With %from like it handles any other HTML tag ...
This is one of the nicest things about my DOM approach. You can
write the form in standard HTML, with default values written there
if you want, and the code will fill it in later.
... but usually you use the "form_for" or "form_tag" helper that Rails
provides:
= form_for @post do |f|
= f.label :title
= f.text_field :title
In the above example :title have to be a column in the Post model. If
the @post instance has a title the text field will have the title as its
value.
There's also a plugin called "formtastic" that should make it even
simpler (although I've never used it):
https://github.com/justinfrench/formtastic
* SASS, generates CSS - http://sass-lang.com/ (I'm using the sass
syntax and not the scss syntax)
Heh, I looked at that not long ago. I'm annoyed by CSS's lack of
nesting.
Not annoyed enough to introduce Ruby to the project, although I
rather like what they did here. I'll probably spin my own version
eventually.
Then I think you should checkout LESS: http://lesscss.org/
Basically the same thing as SASS but without the Ruby dependency.
* CoffeeScript, generates JavaScript -
Eh, I thought about something along these lines, write some
of it, but I decided against going far with it.
There's two reasons:
a) If you're writing enough Javascript to make using a replacement
worth it, you're writing too much Javascript.
I use coffeescript at work where we use the jqgrid library. It's
basically a fancy table with inline editing, and it can do a whole bunch
of other things as well. I have around 450 lines of coffeescript to
control the grid the way we want to have it. We use a lot of custom cell
views and cell formatters.
b) Javascript's biggest problem is that it's loosely and dynamically
typed, not that it's whitespace is ignored.
Well, I don't use CoffeeScript because it uses indentation for scoping.
I use it for its other features. I don't know what I like best in
CoffeeScript but I think it's the syntax for anonymous functions, just
an arrow: ->.
Another thing I really like is it's built in support for rebinding the
"this" variable. In JavaScript if you use an instance method as a
callback to an event function the "this" variable is now no longer the
class instance, instead it's the object that raised the event. If you
use => instead of -> in CoffeeScript it will rebind the "this" variable
back to the instance making it behave all the other languages.
It also has a class based object model which is then translated into the
prototype model used by javascript.
The auto-generated javascript to access my D code make using it
almost easy anyway
http://arsdnet.net/cgi-bin/apidemo/javascript
<button onclick="
CoolApi.getABox('green').appendTo('playground');
" type="button">Get a green box</button>
Those are all basic examples. The idea is the server does most the
work, and Javascript simply plugs it in somewhere in the document -
the same way the page is built on the server side. appendTo's
argument can be a string for a trivial ID or an element as returned
by any of the built in browser functions (such as querySelector -
no need to load up a big piece of shit like jQuery to have that.)
The generic get() function does partial application so it's reusable
with other functions:
function fadeIn(parent, speed, html) { ... }
CoolApi.getABox('green').get(fadeIn, this.parentNode, 10);
Since the server might return data, such might not always work.
That's where the format modifier comes in:
CoolApi.getPeople(0).format('table').get(fadeIn, this.parentNode, 10);
Thus, javascript functions become fairly trivial and/or reusable,
so you don't have to deal with the language very much at all.
Correct me if I'm wrong but that would require a request for bascially
every function call? I don't like that, and I don't like the inline
javascript.
I also toyed with generating Javascript from D:
auto js = new ClientSideScript();
js.alert("Hello, world!");
js.var("wat") = 10;
js.alert(js.wat);
That kind of thing. Each method call to the js object builds a
code string inside it. D variables passed as arguments are
converted to Javascript literals and added to the code.
It actually kinda works, and I use it from time to time, but
only for little things. For the big, I don't think it's worth it.
Ok.
--
/Jacob Carlborg
