[permalink]2017 ...
januari (4) februari (2) maart (6) april (3) mei (4) juni (2) juli augustus (1) september (3) oktober (5) november december (1)
TMongoWire v1.1, now on jsonDoc!
2017-04-04 19:46
mw_1_1
[permalink]
This took more effort than I anticipated, but I'm glad I saw it through. A tiny bit of history: when I started creating a Delphi connector to access a MongoDB instance, I had to create the tools to manipulate BSON, and since I really (really!) hate long lists of overloaded methods, I created something based on Variant values. It works great for ADO, so why not. Some time later I had to manipulate JSON, unrelated to MongoDB, so I took what I got, stripped BSON-specifics, into jsonDoc. There it evolved on its own and gained some useful features.
So it was time to re-work TMongoWire, making it use jsonDoc just like any other project. There's still a bit of BSON-specific code, but it deserves a unit of its own. The downside is there's an extra unit to include in the project, but there were multiple already (jsonDoc, bsonTools, mongoWire and if needed mongoID, mongoAuth3 and mongoStream); the upside is the improved performance and features of jsonDoc, both of the current version and those the future could bring. Enough change to bump that version number:
https://github.com/stijnsanders/TMongoWire v1.1.0
Please let me know if the migration effort this generates is surmountable, and if I can do anything to help. In theory any references to bsonDoc, the BSON function and the IBSONDocument interface should keep working once replaced with references to respectively jsonDoc, JSON and IJSONDocument. The document object no longer implements IPersistStream, but this may have been stretching abstraction just a bit too far. We're on Delphi so plain old TStream should do, and apparently IPersistStream's Seek signature changed a tiny bit over Delphi versions, making it harder to make the code cross-version-ready.
HTML: label, no more "for" for me!
2017-04-13 22:44
htmllabelfor
[permalink]
If only I had known sooner! I forgot where I picked this up, but apparently if you put <label> around an <input>, typically of type checkbox or radio, browsers automatically know the label is for that control. Before, I would write my <input id="x"> first, then a <label for="x"> after. To keep code neat, I would put it on a separate line, but the EOL inbetween would not be clickable to actuate the control. This is a really minor issue, but still. Now that I know you can just write this:
<label><input type="checkbox" name="Toggle1" value="1" checked="1" /> Toggle1: clicking text after a checkbox should toggle the checkbox!</label>
Because, there are two kinds of people: those that click the box to switch a checkbox, and those that click the text right of the checbox. You might not even know that you do, but you do don't you. If you're of the latter type, it's just one of those minor frustrations, that a click on the text-label sometimes doesn't do what you expect, and you have to:
But there you have it. Heaven has great UX. Here we need to make do with what we get. (And need to make sure it's the way we like it for those bits that we have control over.)
2017-04-22 13:12
relaxxxm
[permalink]
→ Delphi Relax Web Scripting (Marco Tech Blog)
I'm sorry but I feel I must react. In general I keep silent, in the hope people by themselves will know better, but as I'm getting no input what-so-ever that that is the case, I feel tempted to write something about this.
First about what's at hand. I see this bit of code:
<h2>Employees</h2>
<ul>
@foreach (var emp in employee) {
<li>@emp.FirstName @emp.LastName (@emp.PhoneExt)</li>
}
</ul>
and it looks kind-of OK. To the untrained eye it looks good and may even look tempting to write more in this syntax. This is a straight-forward example of a template that works with a templating engine that no doubt has many more capabilities and features. And then I thought, learned from practice, what I typically would get asked is to not show " ()" when the PhoneExt field is empty. I would not know how to make that happen in that template syntax. That's mainly because I know nothing about the template syntax. If I look into the documentation, I might find an @if predicate to make it happen, but let's move on:
This is what it could look like in xxm:
[[!var emp:TEmployee;
<<h2>Employees</h2>
<ul>>
foreach emp in FDMemTable1 do
begin
<<li>>=[emp.FirstName,' ',emp.LastName,' (',emp.PhoneExt,')']<</li>>
end;
<</ul>
Looks roughly simlar. A little more like Delphi syntax. And in fact it is. If you know [[, ]], << and >> get translated into Context.SendHTML() and Context.Send() calls behind the scenes (full details are here), you know this code will result in the same output. Without templating engine! Streamed to the user's client! Perhaps even while the data is streaming in from the database server, in case it's a longer list, and in case there is a database server, Marco uses a memory-table for his example.
What I find important is that there's less going on between the native compiled logic and getting the data to the user launching a request. Not only a templating engine looks superfluous, this entire ORM thing is something I don't get. If it's a gigantic database model with so much tables that you clearly benefit from code-completion, then I agree, but I haven't come across something remotely close to that in web projects.
Also the HTTP-server itself is something I think that values extra attention. I've seen platforms and frameworks that offer you a wealth of capabilities and features, but hastily slapped on something that listens on TCP port for basic HTTP requests, in some cases on port 80, but more often 8080 or something else in the thousands. In real web environments, the server(s) has/have a lot more going on: load-balancing, reverse proxies, firewalling, authentication. Since we're in a Post-Snowden-era nowadays, we're all responsible to think about protecting privacy and get that HTTPS in order with the proper certification and encryption... Not to mention HTTP version 2 that's heading full steam towards being generally accepted/expected.
I can image the web-admin responsible for all that, isn't happy with your request to add this newfangled separate thing that's doing its own handling of HTTP requests. ISAPI DLL's or Apache modules play much nicer with existing IIS or Apache installations. (FastCGI is on the table, but for now xxm has SCGI available for other servers.) Even if your 'Delphi HTTP framework' of choice is specifically designed to tap your ORM of choice and offer a REST-API for your data-layer needs, it will still be one more stop along the way between the user's browser, and the delivery-setup, and the front-end, and the page-template, and the data-layer, and the database, and what the user actually needs or wants. I think of this in the postal office when there's twelve people in the queue in front of me.
I don't expect to convince much people of this way of working, but it works great for me. I remember the days with early PHP and ASP and how simple and straight-forward everything was. Knowing these work on scripting engines, I kept worrying about lost performance. This was the core reason to start xxm: employ the speed and power of the Delphi compiler to have a native library serve my websites. And it turns out that Delphi code looks quite nice between HTML to handle server-side logic, if I may say so. It took me a few years to make this happen, but I couldn't do without it any more. And people kind-of appreciate that for using this new application, all they need is their trusted browser and a URL.