On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
otherwise you are free to kill the session once served. The amount of data it holds is only your own design, can be as little or large as necessary.
There are two points:
1. Without caching (and AFAIK Wt does not even has such concept) you'll get stuck very fast. Even C++ is faster then PHP by order of magnitude this will not save you with large DB when queries are not so cheep.
Wt is designed to be outright cached by an external caching program, but it is trivial (and I have done so) to embed caching yourself (and by trivial, I mean it took less then 5 minutes to code up). Quite true with the DB queries, but I am not using C++ here for its speed, I am using it because it is powerful, I know it, and it can potentially do anything that I could ever imagine needing to do anywhere, to get around big DB queries is a design issue, not a language issue. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
2. Web is stateless for 99% percent of visitors. Giving a session to each request IMHO is bad idea.
Exactly, there is no point, designing most of it to be stateless would be fine, although even holding state would not matter much, even assuming some *massive* per-user session sizes of 200kb each still lets it handle far more people then the Boost site would ever get at any single instant. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
True, but it can handle a very Qt style or design (which I personally do not like, nor do I use it), or a very CSS centric style, or any mix.
As I told you, IMHO web is not GUI... Thinking of it as GUI just makes things bad.
I beg to differ, what is HTML if not a way of rendering an interface, and CSS to design a theme, and javascript to make it interactive? Web in general is not a GUI, just as the computer in general is not a GUI, it is just the primary (not the only) way of interacting with the system. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Oh not even, the main advantage of web design in C++ is its powerful capabilities and ability to abstract things away.
This is not about C++, it is about framework.
Exactly, and Wt can do just about anything you need, plus if you are so against C++, use Wt in Java, it is exposed to other languages, not just C++, C++ just happens to be what it is made in. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Since I started using Wt I can get a site running faster then I ever could have with PHP or Python
I'm not talking about plain PHP, or plain Python. I'm talking about using web framework like Django.
As mentioned below, DJango and others are fine, but if you ever really have used them, you find that you run into limitations very quickly, in addition to creating something in Wt is faster due to the need to create templates in those others. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
What I meant by low level is that it has no higher level abstractions as Wt has, it is nothing but pure MVC, where Wt is more like Qt (which is MVS anyway, but like a GUI program, or you can use the lower-level capabilities if you so wished). CppCMS does *not* do near what Wt has, I tried it (I do prefer its license over Wt's),
The point that Wt tries to make web development as GUI.
Only for the parts of it that actually are, if you need to make RSS feeds, serve some static random content, generate dynamic images, or anything else you can imagine, it is made for that as well. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
I think that web developer should write HTML, should write JavaScript (actually using one of JavaScript toolkits like JQuery) and write server side code.
Why should they write HTML? Would you prefer to use the Win32 C API for creating graphical programs instead of wxWidgets, MFC, Forms, Qt, etc...? I certainly would not, I want to get things done fast and have it work everywhere. If I wrote the HTML myself then I would have to deal with all the little bugs from all the different browsers, when Wt handles that all for me. Besides, I do not have to use its QT-like interface, it is trivial to send HTML too, but then you lose advantages like only changing the parts of the page that need updating instead of refreshing everything. Oh, and yes, Wt does use jQuery internally, and it makes it trivial to connect Javascript and C++ together if you have any custom code that needs to be run client-side (as I had a lot of in one of my projects). On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Hiding this behind the "GUI" framework leads to bad design.
So wxWidgets, Forms, Qt, GTK, etc... all encourage bad design? I just do not see that, where is the proof? On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
HTTP connections are not cheap, the signals/slots design make designer to forget when comes behind the scenes.
Exactly, they are not cheap, Wt minimizes the need of them. If you just send a static page, it compresses it in any necessary way. If you send dynamic pages, and the user does a lot of updating in the page that requires lots of little things updated, then Wt combines all the request into one large response and sends in en bulk (compressed of course). Using the signals/slots design lets it combine requests and reduce them very well, far better then any plain HTML setup. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Signals and slots are good when they called withing same process and not over RPC that is passed over HTTP.
Pure signals/slots in Wt are server-side only, designed to be called within the same process, even by different users interacting with each other (see the chat example at http://www.webtoolkit.eu/wt/examples/simplechat/simplechat.wt ), there are two types of external 'callbacks', both which are transparently converted to use server-side signals, and two types of external sent 'signals'. The two callbacks are when a user clicks a url link or a form submit, Wt handles converting that to proper callbacks on the server-side if necessary, and the other is a javascript link, which is the basic type of Javascript callback, such as when you need to do something that cannot be done in javascript (easily) and you want to do it server-side instead, you just create a Javascript slot (jslot) and register a C++ callback method (or more) with it and in your output Javascript code on the webpage you just do this: ...some javascript code and so forth; " << myjslot << "(any arguments); ... some more javascript code; and when that javascript function is called in that position then it causes an RPC callback into the server (combined with any other pending requests of course) to do what it wants, which may or may not cause a client-side change if necessary. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
This abstraction leads to bad code, bad design and total misunderstanding what web is.
I do not see how, where is the proof? Just as the old antiquated windowing systems that are still usable on modern computers exist, no one really uses them, there are always abstractions on top that allow for things like vastly enhanced code readability, easy to add in features, easy updating without changing massive amounts of code-base, etc... On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Good caching is useful, no matter what you use.
AFAIK Wt does not even has such concept... While it is one of the central design concepts of CppCMS - efficient caching.
It does not have one built-in, it is designed to be used with external caching systems, but it is still extremely easy to create your own inside of it, if you really want Wt to come with one then I can submit mine as a patch once I clean it up a bit, nothing special. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
One major difference is that you do not need to write templates as in CppCMS (well, you could also write out raw html from CppCMS), since Wt lets you design it like a Gui app, you can create things *FAR* quicker
I disagree with you that writing HTML slows things down. It makes them clearer, easier to debug and smaller.
And I completely disagree with that. Writing HTML compared to writing *nothing* could in no way be faster. It does not make things clearer, it only adds in more noise with all the other css and javascript crap in the way, and it in fact makes it vastly *harder* to debug due to the way different browsers are broken in different ways, better to not write it and let something else that already knows how to handle all the broken stuff automatically. And again, writing HTML compared to writing *nothing*, noticeable size different there for sure. Also, do note, Wt has a template engine called WTemplate, although you could use any other, or do not use it at all, I have never used it, it does support displaying arbitrary widgets of any complexity too, so you still have the full power of Wt with whatever you like about templates. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
So on and so forth. I tried using CppCMS, but it just does not do anywhere near as much to smooth the workflow in comparison.
- When had you tried it? - Which version? - What had you written with it?
And:
- How much time would it take to write an application like Wikipp in Wt? - What performance will you get?
I tried it when you introduced it to boost when talking about Boost.Locale a few months back, unsure what the version was. I just followed the tutorials then tried to write something interactive as a test (a copy of something I made in Wt a while back). How much time to write an application like Wikipp in Wt, hmm, very short no doubt, I can do so if you wish, but let me look at the Wikipp code first, done, first I see no way of compiling, no cmake build scripts or bjam or anything that will work on the computer I am on now, so just looking at the source. First of all, I notice a templates and mo/p4 directories, I do admit that I have become a bit allergic to templates as of late due to the ease of use of not needing them now (although you can still do them in Wt no doubt), but I do notice that whatever template language that is, it is quite hard to read, all this template code and HTML mixed together, it seems you have to manually handle sidebars and so forth, easy potential for things to break, and the generated cpp from it is even harder to read, while no doubt requiring a pre-processing step. As for the mo/p4 directories, obviously for internationalization. Wt's, I admit, is not as advanced as Boost.Locale (although they will probably use Boost.Locale should it end up in Boost anyway), but theirs is made up of simple xml files, different directories for different languages, different files for different sections of the app, not just for localization, but can also be used for theming in a different way letting you use arbitrary html and so forth (if you let it). It would be simple to use Boost.Locale within Wt as-is though, it does not absolutely mandate styles. As for the actual code, the main application seems to be about as long as the Wt version would, although I wonder how this line works: url.add("^/(\\w+)(/.*)$", boost::bind(&wiki::run,this,$1,$2)); I notice there are a lot of things that are done in CppCMS that take a lot more code to do, like a simple redirect takes two lines (which includes instancing a HTTPRedirectHeader), compared to a simple app->redirect in Wt (which can take a url or widget location, where CppCMS seems to only take a url). Here is the important part of the page display function: """ void page::display(string slug) { this->slug=slug; sql<< "SELECT title,content,sidebar FROM pages WHERE lang=? AND slug=?", locale,slug; row r; if(!sql.single(r)) { string redirect=edit_url(); set_header(new HTTPRedirectHeader(redirect)); add_header("Status: 302 Found"); return; } ini(c); r >> c.title >> c.content >> c.sidebar; render("page",c); } """ This same function in Wt might be this (using its own DB system, which is still rather new, but you could use any other if you wanted): """ void page::display(string slug) { this->slug=slug; dbo::Transaction t(*session_); dbo::ptr<Page> page = session.find<Page>().where("lang = ? AND slug=?") .bind(locale).bind(slug); if(!page) { string redirect=edit_url(); app->redirect(redirect); return; } title->setText(page.title); // This is set to show html as text content->setText(page.content); // This is set to pass through html, after making sure it is clean. } """ The rest of the functions also look like they would go quite fast to convert. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
It took me about several evenings only to write such application from the begging to the end including testing, and deploying and fixing CppCMS bugs I had found.
And it was first serious CppCMS application.
Making such a Wiki would probably take even less time, and add an RSS feed for latest updates in one more function, and etc... On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
It holds about 2,500 requests per second on 1CPU machine.
I can see the Wiki being very DB constrained, so it would be tough to compare this, perhaps a dynamic non-DB page generation request? Do note, Wt's DB is very low level, using constructed queries and other such optimizations, all available for re-use without needing to regenerate. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Ditto, and a couple years of experience with Wt, and a decade with PHP, and a **few months** with CppCMS.
Good point.
I was searching for C++ web frameworks a while ago, CppCMS never came up, so that is why I did not notice it until your Boost post. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
Summary: --------
- Developing web application as you develop GUI is not suited for general web development
Oh it very much is well suited for that, well, if you are making an interface, for RSS feeds, image generation, *whatever*, Wt has things for that too. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
- Signals/Slots mode has big overhead and hides too much from developer.
I do not see how it hides anything, it seems to make connections between things very explicit and clear, while being executing quite fast and being very simple to use. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:
- HTML and templates are essential for web development, hiding them behind Qt like "layout" abstracts brings back and not forward.
HTML and templates are like working with the base C API for a windowing system compared to all of the graphical toolkits built on top. Using that low level API gains you *nothing*, since everything higher can do everything anyway, but the higher levels also help you to design vastly easier to reuse components and helping to vastly reduce the amount of bugs while reducing programming and testing time. On Wed, Jun 2, 2010 at 8:14 AM, David Abrahams <dave@boostpro.com> wrote:
At Wed, 2 Jun 2010 00:10:39 -0600, OvermindDL1 wrote:
I certainly know that is not true when hosting on Windows, on *nix I believe it uses FastCGI. The user session data is only important for when the user *has* a session (logged in or so?), otherwise you are free to kill the session once served. The amount of data it holds is only your own design, can be as little or large as necessary.
Wow, this Wt thing looks really, really cool. I don't suppose they want to be part of Boost?
I would doubt it, it is a sub-project of the Emweb company with dual GPL/Commercial license, they only keep it running and updating to support their own efforts, like the Qt/Nokia relationship. Personally I question some of their design decisions, it would be quite interesting to create a replacement that is better optimized (in the boost style) with all that power. I can propose the question though. On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:
At Wed, 2 Jun 2010 00:10:48 -0700 (PDT), Artyom wrote:
Ditto, and a couple years of experience with Wt, and a decade with PHP, and a **few months** with CppCMS.
Good point.
Summary: --------
- Developing web application as you develop GUI is not suited for general web development
You haven't given any evidence to support this claim AFAICT, but I may have missed it.
Ditto, I have been wondering about that statement too, I have seen no claims for it, and many against it. On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:
- Signals/Slots mode has big overhead and hides too much from developer.
I can understand that argument. Not sure I agree that it hides too much, but at least I understand it.
I am not really sure how it hides anything, I have lots of things scattered about my code like this: userLoggedIn->emit(user); clicked().connect(bind(&newPost, this)); string createImageCall(createImageCallback()+"(type, h, w, text, 'png')"); { JSlot *callOnClient = new JSlot(javascript, this); callOnClient.exec("null", "null"); // On the next request to the client, this will be sent along with all of the other data and executed } etc... This all *vastly* simplifies the code and makes things very explicit On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:
- HTML and templates are essential for web development, hiding them behind Qt like "layout" abstracts brings back and not forward.
This seems to be an entirely subjective statement. I'd like to understand whether it's the same as saying “machine instructions are essential for coding; hiding them behind Pascal-like ‘high-level language’ abstractions brings us back and not forward,” which I would reject on its face, or if there's something more to it.
Note that I don't reject all such arguments. For example, I believe that today's typesafe languages force us too far away from the machine model to achieve the highest efficiency. But then, that's phrased as a tradeoff between safety and efficiency; your statement isn't.
That is exactly why I like the Wt model, it lets you do things in the high level, in templates, in raw HTML, or anything else you can come up with, while letting you mix-and-match it all as you wish.