How To Dynamic Web Rendering?

[Jacob Carlborg]

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