On 15/05/2011 22:46, Alexander wrote:
> On 15.05.2011 23:05, Nick Sabalausky wrote:
>
>> And like I said at the beginning, the old-style-PHP/ASP of mixing
>> code and HTML is one of the things that *HAS* become widely
>> accepted as bad practice.
>
> Could you please back your claims with something? I know already that
> you are the kind of person who knows better, and you are used to
> speak for everyone, but that's just words.

I can't be bothered collecting lots of references, but having done web development both professionally (not as much as Nick) and non-professionally, I can tell you that it *is* widely accepted as bad practice.

I've found the people that don't agree with that are either (reasonably) new to web development, or don't really know what they're doing.

>> Just because there are some amateurs and incompetent
>> "professionals" around that still don't know any better doesn't
>> change that fact.
>
> And you are professional? Show me something that is professional, so
> I can learn.
>
>> Ugh, I never could stand that hippie rhetoric. Despite what
>> society's been brainwashed into believing, there *ARE* opinions out
>> there that are just plain moronic, and yes, *wrong*.
>
> And yours is always *right*? ;)

Meet the seasoned web developer - 99.9% of other web developers are idiots who can't code, and anyone who does it differently to you is wrong.

After a certain amount of time working with the web, and several code bases that started as quick hacks to get the job done but evolved into entire websites with a good few users, you realize that most of the code out there is terrible. It gets the job done, sure, but it takes a lot of effort to debug or add new features. Anything you add to the code base just makes it harder to maintain, even if you start writing things properly. Want to re-factor something? Chances are you can't do it without breaking something.

If you're curious, add:

error_reporting(-1);

To the start of most PHP applications, and see the large number of notices/warnings/errors which scroll past in your error log - over time the PHP developers (not developers that use PHP) have realized how many things can go wrong (register_globals, magic_quotes, safe_mode, etc), and added more warnings, notices and errors which aren't shown by default. I've encountered a good few developers which have said I shouldn't have enabled it and it's not their problem when working with their code. Note that things like wordpress use error_reporting() elsewhere, so adding error_reporting(-1); won't make any difference as it will be overridden.

Of course, I'm not saying Nick is always right (I happen to disagree with him on a few things, just mention javascript to him to see what I mean :D), but you now have 3 developers with varying experience with the web telling you it's not the right thing to do. Sure, it's fantastic for quick sites, nice and fast to put something together... But when it evolves into a something bigger it will be a nightmare. Using a decent framework is just as fast, and it's easy to maintain later on.

As for using D for web development... I'd use it even without a web framework, purely for the maintainability/error reporting issues mentioned earlier on. There are no frameworks available that I'm aware of other than Adam's currently (which I believe he's using professionally, so it has to be reasonably good), but something is better than nothing. I'm also working on my own, progress is slow though due to time constraints. Give it a few months and it might be workable.

> /Alexander

Seems I managed quite a rant there. Oops :D

-- 
Robert
http://octarineparrot.com/

On 15/05/2011 22:44, Alexander wrote:
> On 15.05.2011 22:56, Nick Sabalausky wrote:
>> It *barely* works. And I *did* stop using it specifically because it worked
>> so poorly.

+1

>    Don't get it too personally, but probably, you didn't read the manual? ;)
>
>    It works perfectly, even for those who are *not* familiar with software of web development.
>
> /Alexander

It most definitely does not work perfectly. You highlight those that are not familiar with web development? They're the ones that use it.

Visual Studio defaults to not using it now, there's a reason for that. I don't know about PHP IDEs.

-- 
Robert
http://octarineparrot.com/

I wrote:
> When I wrote my http code,

I just spent a little time updating this. It's still built on my
old netman.d, which uses Linux system calls so prolly linux only
(it does select() and friends directly, should be easy enough to port
to WinSock or std.socket but I wrote what I knew and left it at that).

Removed some of the logic since the CGI class does it in a more structured way, and added support for HTTP 1.0 and better support for non-conforming clients.

These steps aren't really necessary to work - today's browsers
know to use \r\n and HTTP 1.1, but the ab program - apache benchmark
- does not, and I wanted to see what happens when I attack it.


Cache headers (if-modified, etc.) are not handled properly on the server, and cgi.d doesn't expose them at this time. This thing isn't meant to be used in production, unless it's in the back end, behind something more battle tested and standards conformant, like Apache.


That said, ab's results weren't too bad if and only if the handler runs quickly. The reason for that is it is single-threaded. (the network manager class is based on a cooperative multitasking setup - each connection gets it's onDataReceived function called when new data comes in. It needs to look at it and return as soon as possible. Fine when it's all simple code, but with more complex websites it probably won't be.)


While it's only a couple hundred lines long so I can't complain too much, this concurrency issue will have to be addressed before I can say it's really suitable for serious work.


... but, it is good enough to function as a notification server! Async notifications are fast, even if single threaded.

Anyway while the implementation needs work, I am pretty happy with the api.


Here's some code:

import arsd.httpd;

// the handler function is identical to one written with standard
// CGI
void handler(Cgi cgi) {
	cgi.write("Hello!");
	cgi.write(to!string(cgi.get)); // show dynamic output
	cgi.close();
}

// but instead of mixing in GenericMain or whatever, we call
// serveHttp.
void main() {
        // function pointer to handler, port to listen on
	serveHttp(&handler, 5000);
}



Nice and simple!

Robert Clipsham:
> which I believe he's using
> professionally, so it has to be reasonably good)

Indeed, cgi.d, mysql.d, and dom.d have both been used on a few of my client's live sites for about a year now. If they have serious bugs, I've subconsciously learned to avoid them, since there's been little problems with them. sqlite.d and postgres.d seem to be ok, but haven't gotten as heavy use as mysql.

The newer web.d, that I've been linking to as the apidemo, is
used for some in development apps, but nothing that's launched
yet. (Everyone is very excited about these in-dev apps though, it's
been excellent during internal testing and I've made excellent
time developing new features with it.)

There's a number of helper modules too that work well, but are more tied to the application itself, so I haven't released them. (If there's potentially anything proprietary in a file at all, I hold the whole thing back unless I can find the time to carefully comb through it.)

The two most likely to go public before too long are:

email.d for talking to sendmail, Gmail relays, and recently added, Amazon SES. Also minimal includes MIME attachment support and a html to text converter for automatically making multipart messages. (they write html emails but I loathe them.)

oauth.d for interacting with Facebook's apis (oauth 2) and Twitter,
LinkedIn, and (buggy) AWeber (oauth 1). As of last night, it also
has a minimal oauth 1 server implementation. Needs lots of testing.


It's a pretty wide collection of stuff, with the base reasonably well tested. Most of it is nothing fancy though.

On 16.05.2011 01:25, Robert Clipsham wrote:

> It most definitely does not work perfectly. You highlight those that are not familiar with web development? They're the ones that use it.
> 
> Visual Studio defaults to not using it now, there's a reason for that. I don't know about PHP IDEs.

  I am sorry, but do we talk about the same thing? How is WordPress related to Visual Studio, especially how could it "use it"?

/Alexander

On 2011-05-15 17:46, Adam D. Ruppe wrote:
> Jacob Carlborg wrote:
>> I don't see anything wrong with the view layer containing simple
>> logic, like this (written in HAML):
>
> I don't think it's bad - I just think it isn't as good as we can get.

Correct me if I'm wrong but you don't like to have logic in the view layer. Instead you move the view layer into the model or controller layer. How's that any different?

-- 
/Jacob Carlborg

On 16.05.2011 01:21, Robert Clipsham wrote:

> I can't be bothered collecting lots of references, but having done web development both professionally (not as much as Nick) and non-professionally, I can tell you that it *is* widely accepted as bad practice.

  Accepted as bad practice by whom? Looks like there is very small fraction of "real" web developers, who is deciding what is "bad practice", as almost anything which is public widely using it.

  Times change, and something was considered as "good practice" may change to "bad practice" in few years, and vice versa - I've seen that enough in last 20 years.

> ...but you now have 3 developers with varying experience with the web telling you it's not the right thing to do.

  I am sorry, but I didn't see any works of those web developers (I mean - the code), so I couldn't make my mind - what is *good* practice, and why it is better than anything else (again - *if done properly*).

  Good practice, from my point of view, is something that:

  - Easy to understand;
  - Easy to maintain;
  - Easy to extend;
  - Does its job well (according to specifications);
  - Has good performance;
  - Doesn't have any holes.

  So, it doesn't matter, how exactly specific solution is implemented, as long as all of those point are met. I can mix code with data or use DOM templates - as long as I fulfill the above stated requirements, it really doesn't matter.

  It is like my recent question about class member declaration order - I find it harder to understand the code, when members are not declared before use, though, others (on this list) tend to disagree with me. Who is right here?

/Alexander

"Alexander" <aldem+dmars@nk7.net> wrote in message news:iqqq9p$ka6$1@digitalmars.com...
> On 16.05.2011 01:21, Robert Clipsham wrote:
>
>> I can't be bothered collecting lots of references, but having done web development both professionally (not as much as Nick) and non-professionally, I can tell you that it *is* widely accepted as bad practice.
>
>  Accepted as bad practice by whom? Looks like there is very small fraction
> of "real" web developers, who is deciding what is "bad practice", as
> almost anything which is public widely using it.
>

The vast majority of web developers *are* very, very, poor coders. Being correct and being in the majority have absolutely *nothing* to do with each other.

>  Times change, and something was considered as "good practice" may change
> to "bad practice" in few years, and vice versa - I've seen that enough in
> last 20 years.
>

That's an enormous oversimplification.

>> ...but you now have 3 developers with varying experience with the web telling you it's not the right thing to do.
>
>  I am sorry, but I didn't see any works of those web developers (I mean -
> the code), so I couldn't make my mind - what is *good* practice, and why
> it is better than anything else (again - *if done properly*).
>
>  Good practice, from my point of view, is something that:
>
>  - Easy to understand;
>  - Easy to maintain;
>  - Easy to extend;
>  - Does its job well (according to specifications);
>  - Has good performance;
>  - Doesn't have any holes.
>
>  So, it doesn't matter, how exactly specific solution is implemented, as
> long as all of those point are met. I can mix code with data or use DOM
> templates - as long as I fulfill the above stated requirements, it really
> doesn't matter.
>
>  It is like my recent question about class member declaration order - I
> find it harder to understand the code, when members are not declared
> before use, though, others (on this list) tend to disagree with me. Who is
> right here?
>

When you're not doing trivial stuff, the traditional mix-code-and-html approach fails miserably at:

- Easy to maintain;
- Easy to extend;
- Doesn't have any holes.

And it also causes this to become a bigger and bigger problem as a project progresses:

- Easy to understand;

All of that, in turn, makes this MUCH, MUCH harder than it would otherwise be:

- Does its job well (according to specifications);

On 16.05.2011 12:23, Nick Sabalausky wrote:

> The vast majority of web developers *are* very, very, poor coders. Being correct and being in the majority have absolutely *nothing* to do with each other.

  Sorry, but I still don't get it - who is defining what is correct and what is not? And why?

> When you're not doing trivial stuff, the traditional mix-code-and-html approach fails miserably at:
> 
> - Easy to maintain;
> - Easy to extend;
> - Doesn't have any holes.

  Why it fails here? Why it doesn't fail for me? Or some other people? Sure there are always poor coders who could fail anything, but not everyone.

> And it also causes this to become a bigger and bigger problem as a project progresses:
> 
> - Easy to understand;

  As long as you follow some simple rules when coding, nothing bad happens. On the other hand, there always people who don't understand your code, and you - theirs.

  What is difficult for you, may be piece of cake for someone else, and vice versa - it is all bound to how your barin works :) Some people easily and in few minutes do sophisticated stuff in languages like BrainFuck, while for me that will be
exactly what name of this language means.

  Exactly the same thing applies to web development (and any development) - is it easy to understand or not, depends on who is trying to understand.

  And no, you simply cannot make something very complex so easy that anyone will understand it like you (the author) do.

> All of that, in turn, makes this MUCH, MUCH harder than it would otherwise be:
> 
> - Does its job well (according to specifications);

  I know personally at least one project, which fail miserably in many, many points - but does it's job *very* well for more than 10 years. How is this linked then?

  Or, look at djb code (qmail & co) - the code itself is terrible, still, one of the most used - and less buggy that many "well designed" and "good practiced" projects.

  The only example of good code and good practice that I ever knew is cryptlib, though this is not exactly related to web development...

/Alexander

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