Render a skeleton of the page the main page load, and populate the full contents asynchronously. Surely that's the whole reason you wanted to use AJAX in the first place, so it is the best practice.
For the most part, yes. Initially however I'm making a call that loads a
bunch of system configuration (in JSON format) and populates a bunch of data
structures. This determines how the remainder of the page gets rendered.
Once that's done, nearly everything else can happen asynchronously.
Admittedly, however, I am a n00b to writing web applications this way, and as soon as it's implemented past the point of no return I'll figure out a better way to do it.
Once that's done, nearly everything else can happen asynchronously.
Admittedly, however, I am a n00b to writing web applications this way, and as soon as it's implemented past the point of no return I'll figure out a better way to do it.
of data structures. This determines how the remainder of the page gets
rendered.
Then it sounds like you need to render *almost nothing* on the main page load. Render everything from Javascript.
It's either that, or do more of that first, skeletal rendering server side, the old-fashioned way.
Isn't that how you're supposed to do client-side web apps anyway? Just a
couple of div's for the basic layout and then everything else in javascript?
What I ended up doing is running the initial JS piece on page load and then having that function's OnComplete (or whatever it's called) call a function that loads all the other pieces that depend on it. I suppose that's "how it's supposed to be done" but it still seems a bit obtuse to me.
What I ended up doing is running the initial JS piece on page load and then having that function's OnComplete (or whatever it's called) call a function that loads all the other pieces that depend on it. I suppose that's "how it's supposed to be done" but it still seems a bit obtuse to me.
I have written a fairly significant amount of Rails code lately.
I thought we should embrace it, as the rest of the company uses it for their efforts, so we could potentially pull from a larger pool of people in the future if we ever needed to do so.
Although I'd never used this before, I find this environment impressive.
Although, getting something up in production seemed to involve installing the world.
I might have an illness.
I've been spending my free time writing a C++ header library to act as an HTTP 1.1 client.
Handling chunked transfer encoding or regular 'identity' transfer encoding, getting headers, able to write the body either to memory or file, etc.
I never found a truly C++ library that quite did all of this the way I want, so I figured I should write my own. There's this one guy, named Falco, working on something that looks nice, but it requires C++11 or better, and I don't want to be limited to newer compilers for this.
I think after I get the client side working, I want to see how much of this I can reuse/rework for server side. I'll never replace apache, but if someone needed an embedded http 1.1 server, maybe I can make this interesting.
(And, yeah, it can handle http or https... technically, I think it could transfer across serial ports or any other transport if you built the low end for it).
waitwaitwhat? All this getting done in headers? Is C++ truly this brain
damaged or am I missing something?
Pretty much, yeah. Doing everything with templates and type-safety means doing it in headers. It's a suboptimal state of affairs.
Well, one could turn it into a proper .lib or .so library if desired, but why bother when you can distribute a bunch of headers and not have to worry about how the shared object was compiled, or with what will it link?
compile time. an object-oriented http library, which is reasonably full-featured and modular, is going to be highly layered and rather large.
you may be building something lean and mean that's just good enough for your needs, but not really general-purpose.
Yeah, header libraries can increase compile time when you do things like include base headers that include tons of other header files, instead of just pulling the header files you need in the library.
If you build the header library carefully, you can reduce the compile to just what is needed, which often doesn't require that much time to compile.
And if your compile times *still* grow to something kind of nuts, you can probably do something clever with your own implementation files to reduce compile times, by moving the often-changing stuff to places that don't pull in header libraries.
Eh, I probably just haven't had a big issue with compile times. My current project requires about 7 minutes to fully compile everything (both 32 and 64 bits, so I have to compile everything twice).
On an unrelated note, I saw something today that does a great job of explaining why 'const' is a good thing, and not to be trifled with.
void a(std::string var) {
char* tok = strtok(const_cast<char*>(var.c_str(), " ");
while (tok) {
fn(tok);
tok = strtok(0, " ");
}
}
int main() {
std::string var = "moo bark quack";
a(var);
return 0;
}
(aside from not having created 'fn()'), this code is evil.
You figure, "Oh, no big deal... a() uses a copy of the std::string, since this isn't passed by reference, so the const_cast won't lead to any problems."
Except you didn't know that some vendors won't actually copy the string used by the std::string class until some operation takes place that requires it... and .c_str() isn't that operator, since it's protected by const.
So, your function now leads to side effects that burns your coworkers.
const's virus-like behavior is quite challenging in C++. Java probably strikes a better balance by simply accepting that some things are out of our control at compile time.
Maybe, although in this case, it did its job.
My eye zeroed in on the const_cast immediately, and it highlighted the problem.
I was able to deduce the issue and solve the problem in very short time because I could see something odd was going on (one almost never needs to const_cast... it's just one of those things that screams at you when you see it).
It's like type safety... I know tons of people hate it, because it seems to prevent people from getting code written, but that early detection helps avoid many terrible issues that come up when you accidentally mix types. Seeing things like reinterpret_cast or static_cast helps draw your eye on possible problems when you're trying to figure out why something went off.
In Java, the type system is just less expressive. Primitive types can be "const"; actually the word for this is "final" in Java. A reference to an object is a primitive type. If the reference is "final", the reference can't be modified but the object it refers to *can*, so long as there is at least one non-final field in that object. Unlike C++ there's no notion of a struct or class that contains non-const fields but a particular instance of or reference to the struct could be declared const. So you can't express quite such binding constraints in the type system.... but you spend less time fighting with the compiler because of somebody else's lack of foresight.