A JavaScript-heavy solution
Ivan
solutions both of which are not really perfect, we could make the
server-side logic purely data-oriented, and move the dynamic HTML
generation completely to the client side where it is implemented using
JavaScript. This way the interface to the server-side logic will
resemble a set of API functions rather then a set of HTML pages. The
data returned by those functions could be in the XML or JSON form. The
data can be either embedded into the served pages using a very simple
HTML generation step or fetched using AJAX.
This solution has a couple of advantages. First is that we achieve a
complete decoupling of the data processing logic from the presentation
logic while still having a full-blown programming language to use for
the generation of HTML. The pages remain completely compatible with
any HTML editing tools and editable/debuggable by the designer without
touching the server-side code. The other advantage is that the
interface to the system is much more general and resembles something
like the API that Aleksey has suggested.
Arseniy Alekseyev
> logic while still having a full-blown programming language to use for
> the generation of HTML.
So, instead of that one I'd mention the other advantages:
* Lightweight network protocol and server code - the server will
potentially be able to handle much larger number of clients, and the
overall responsiveness of the site will be better
* No page reloads are necessary - great usability improvement!
* Inevitable introduction of some new AJAX functionality will blend
naturally with this approach and will probably require less of the
server logic modification.
The main disadvantage is that it would require programming in, guess
what, Javascript, which is a weakly-typed language, so programming
well in it requires much discipline, thorough unit testing and a
strong nervous system. Are there people bold enough to try it?
I've just thougt of another disadvantage -- this approach will not
work with Javascript-unaware browsers (or those having Javascript
disabled). The support for pure HTML browsers may be important.
Ivan V. Polyakov
This is not great at all. This breaks "back" and "forward" buttons
(unless there is some way to replace their handling, probably there
isn't for every browser) and violates consistency w.r.t. conventional
site structure.
> The main disadvantage is that it would require programming in, guess
> what, Javascript, which is a weakly-typed language, so programming
> well in it requires much discipline, thorough unit testing and a
> strong nervous system. Are there people bold enough to try it?
You aren't supposed to write an OS in it though, it's mostly
straightforward HTML generation. Not much worse than writing HTML by
hand :)
> I've just thougt of another disadvantage -- this approach will not
> work with Javascript-unaware browsers (or those having Javascript
> disabled). The support for pure HTML browsers may be important.
Also ZX Spectrum computers will probably be too slow to execute all
the JavaScript. Supporting them may be important (we must make sure
that, e.g., Ashur is comfortable using the site!)
Ivan V. Polyakov
Well, that is your opinion. That you are so stubbornly supporting it
does not mean that it is necessarily true.
Arseniy Alekseyev
this problem, so it should be possible.
> ZX Spectrum
I'd not compare browsers with JavaScript disabled to ancient
dinosaurs. I heard they are still used. :) There should be a reason
for GMail still providing a plain HTML interface.
> Well, that is your opinion.
That is undeniable truth w.r.t the exact part I quoted. Please read
carefully. There are other valid points of disagreement, but this one,
seriously?!
Andrey Mokhov
the system, I see that potentially this approach can have certain
benefits. Let me first clarify if I understood Ivan correctly:
1) Server has two responsibilities
a) storing simple template-like HTML pages that do not actually
contain any data
b) supporting some set of API-calls for actual data fetching (via
HTTP protocol)
2) There can be different types of clients
a) a web-client, i.e. a Javascript function fetching data to fill
in an HTML template
b) a stand-alone contest application (think TopCoder Arena)
c) an automatic algorithm/theorem-proving software as in Alexei's
proposal
Now if the above can be implemented, I see a big potential and
flexibility behind the approach:
- One server can serve different types of clients; data is sent in a
non-HTML-encapsulated way
- (initial) HTML pages are as simple as possible (I love simple HTML
pages!); Javascript and CSS are stored separately
- By implementing this approach we already make a significant step to
Alexei's generalised framework
- Server code is pure data-driven, so Haskell can be used directly
without any Hamlet/Heist/HSP stuff
Costs are:
- Need to do HTML-generation in Javascript; can be ugly.
- Browsers have to allow Javascript; I think this is okay, even
ancient mobile browsers supported Javascript, didn't they? Does anyone
forbids Javascript due to security reasons?
Ivan V. Polyakov
> this problem, so it should be possible.
They change the address on top somehow, I don't know if that involves
reloading the page but it changes.
>> ZX Spectrum
> I'd not compare browsers with JavaScript disabled to ancient
> dinosaurs. I heard they are still used. :) There should be a reason
> for GMail still providing a plain HTML interface.
Well, theoretically that's a valid concern but IMO not really
significant at this point. You could add a pure HTML implementation
later if it proves to be needed, especially if you have a good web-API
this shouldn't be a problem at all.
>
>> Well, that is your opinion.
> That is undeniable truth w.r.t the exact part I quoted. Please read
> carefully. There are other valid points of disagreement, but this one,
> seriously?!
>
Depends on what do you mean by "HTML combinators". I thought you meant
the generation of dynamic parts of the HTML in the server code.
Ivan V. Polyakov
>> carefully. There are other valid points of disagreement, but this one,
>> seriously?!
>>
>
> Depends on what do you mean by "HTML combinators". I thought you meant
> the generation of dynamic parts of the HTML in the server code.
I think I know what you mean, you mean that you can also separate the
data processing and the HTML generation cleanly on the server side,
which is true. What I meant was that this logic gets completely
removed from the server-side code which may be good for the other
reasons you mentioned. Anyway, claiming "undeniable truths" in such
opinionated discussions makes you sound like a zealot :)
Arseniy Alekseyev
following the "#" symbol. Such change does not force the page to
reload, however seems to create a browsing history entry. Clever! :)
> which is true
See? :) My logic is undeniable! (c)
Zealots are cool btw.