Sluggish behaviour in WeBuilder

[Mot]

Cursor lag is all but gone now. Nice job!

[davenz]

Cursor lag is all but gone now. Nice job!

Hmm, not here I'm afraid. The editor still gags on my machine with only a moderate amount of text. Expression Web, CoffeeCup HTML and Namo WebEditor handle HUGE amounts of text without any bother or slow-down at all; WeBuilder goes stupid with a fraction of that amount, even with all code helpers, auto-this or that turned off. Good that it doesn't do it on your machine, though I wish it performed better on mine.

Dave.

[chrisjlocke]

Dave- Even with line breaks in the text?

[davenz]

Dave- Even with line breaks in the text?

Yes, though the lag is noticeably(?) reduced. I'm trying not to be pedantic, but as I said in the first place; having to modify how I do things to workaround what I consider a flaw in the editor is not what I would be calling 'a fix'. As I also said; I'm no coder so I don't know how 'real' programmers do it; perhaps it is standard practise to put line breaks at the end of every line of code.

All I know is my other editors, which I used for many years and have since replaced with WeBuilder, didn't gag when I loaded a text-heavy page into them; until I started using WeBuilder I had never even seen such behaviour. I mentioned it initially because I thought it to be a bug and was shouted down. Don't get me wrong, I really like this software as it is by far the best HTML editor around; I have purchased four Blumentals products so far and will probably buy more. I continue to use WeBuilder every day to maintain and code my wide variety of sites and have even recommended it to readers of my newspaper column, so I am not getting all pissy about it. I would just like to see this particular behaviour fixed. I have no illusions; I assume because it has already been considered fixed that there will be no further work done to address these performance issues. That's fine, no software is perfect and I don't expect it to be; we have to live with quirks with everything from Windows to Word; when required I will simply use another editor to do those tasks WeBuilder cannot do.

Dave.

[Karlis]

No, this is not being considered as a case-closed. I'll need you to send in sample files so that we can do some load tests...

[snorkytheweasel]

Would it help to take those mountains of text out of the page with the code and put that text into include files? For example, make each chapter one include file, and call one or more includes from a coded page.

I really, really, really prefer to separate my code and content as much as possible. That way I can edit the include files without risking damage to the code.

Many of my pages have only a few lines of code: doctype, html, head, body, a few divs and as many includes as needed.

If I use the same menu on more than one page, I code the menu as an include file, and call the menu file from each page that uses that menu. If I want to change the menu, I only have to change it once, and all pages are automatically changed.

If there is a better way to accomplish this, I'd appreciate hearing about it.

[davenz]

That sounds like a good idea. My pages aren't that large though; check out this one:

http://kickopiates.com/

That page, if I don't use P tags to separate the paragraphs, chokes WeBuilder. Realtively, it is not a large amount of text. I know that I should use P tags and that's what they are supposed to be for, I openly admit I am a lame coder, a begeinner after all, but my feeling is WB shouldn't choke unless an absolutely stupid amount of text is entered; then one would expect it to break. As is stands, my computer is no slouch and besides, my other usual editors handle even ten-twenty times that amount of text no problem whatsoever; if I have half this page in WB in one tag, the software hangs. Bad coding and practice? Yes, no doubt about it. Something going on in WB as well? I think so.

The way you describe would be ideal for big sites, though my sites are generally nowhere near that large, or even large enough to make using includes seem worth it. Is it generally good practise to do things like that or is this something you just do?

Dave.

[chrisjlocke]

Is it generally good practise to do things like that or is this something you just do?

Anything that saves time and reduces problems is good practice! As a Visual Basic coder, its a regular 'technique' that if you need something in more than one place, you write a subroutine for it and call that in the two places. It keeps the program smaller, and as mentioned, if you want to make a change, you only have to do it in one place.

In your example of an include file, it would help if the text was separate so that if you needed to edit the text, its separate from the actual code. This also allows someone else to edit the file without them damaging the rest of your site.

[davenz]

Cool, thanks, I appreciate the advice.

Dave.

[mwb1100]

That sounds like a good idea. My pages aren't that large though; check out this one:

http://kickopiates.com/

That page, if I don't use P tags to separate the paragraphs, chokes WeBuilder.

I downloaded that page and took out all the <p>/</p> tags and put one set of <p>...</p> tags around the whole set of text in the "maincell". I'm not seeing any sluggishness in WeBuilder (9.1.0.98) - are there any particular setting(s) I should set?

[snorkytheweasel]

I learned early on to use includes. My background in programming is C, C++, and Pascal - and BASIC (pre-visual basic). When I was still lucid, I even did some programming in Assembler (look it up). Suddenly I feel very old .

The big advantages to PHP includes are

• modular code that is easy to understand
• modular code that is easier to maintain and debug
• separation of code, data, and formatting

By the way, style sheets called from

Code: Select all

<head><link rel= "...."></head>

are a very common kind of include file

In the higher-level languages (the C and PASCAL families), Includes & Header files are considered to be "best practices." In some (most? all?) shops back then they were mandatory. If you sent in code for review, and you didn't use includes and headers, you could count on getting your code sent back with a note that was terse and rude.

Includes rock!

[davenz]

That sounds like a good idea. My pages aren't that large though; check out this one:

http://kickopiates.com/

That page, if I don't use P tags to separate the paragraphs, chokes WeBuilder.

I downloaded that page and took out all the <p>/</p> tags and put one set of <p>...</p> tags around the whole set of text in the "maincell". I'm not seeing any sluggishness in WeBuilder (9.1.0.98) - are there any particular setting(s) I should set?

I apologise, I have just tried that page and you are right; I remembered that particular page causing problems, but I must have been mistaken. I'm sorry to waste your time. To be certain, I have created a couple of test-case pages that exhibit the behaviour I am talking about and they can be found here:

http://www.pcanytime.co.nz/wbtestcase.htm and

http://www.pcanytime.co.nz/wbtestcase3000.htm

Edit: I have just noticed something when working on these pages that may help the devs, should they wish to do anything further on this (see below). At low word numbers (around 1000), the lag only happens when typing inside the tag itself, and then only if I hit the space bar. If I type a bunch of letters together, I can type in twenty to thirty letters without any delay at all; as soon as I hit the space bar though, instant lag; I have to wait for the cursor to play 'catch up'. At higher word numbers, things get stickier, and at 3000, WB is almost starting to become unusable on my machine due to lag, this time bogging down the whole editor. Of course, this all depends on the computer; mine is not a modern beast but it is still very quick; I run a computer service company so I know hardware and how to get the most out of it. Milage will vary on different machines, though I imagine this issue would manifest itself obviously on a lower-spec machine.

The thing is that all this is now moot. This thread is not what it was when I started it and I am almost embarrased by it now. Back then I considered it might be a possible bug that this was happening; now I see it isn't. No one is going to put 1000 words into one tag; I know I did, but that was part of my learning curve and I changed the way I did things as soon as I saw the error of my ways. Karlis posted a workaround, and others who know better suggested superior ways of doing things; that has pretty much resolved the issue for all intents and purposes. I am being too bloody-minded about it. It is a bit like claiming my car is unsafe because the tyres fall off if I go over 300 miles per hour. It doesn't matter if other editors can cope with a zillion words in a single tag, so what? This thread has beome moot itself so I won't say any more on the matter.

Except this: I created these test cases for those who wanted to see what I was talking about. I didn't imagine it; it does happen. It is all academic though because in the real world, it will probably never be seen. I believe the latest build of WB had some fixes for delay issues and this has helped things a lot. It will be interesting to see if the test pages exhibit the same behaviour on your machine.

Back to the real value in this thread; includes look like a good way to go. That's what is so good about this software (and this forum); using WYSIWYG software I didn't learn anything (because I didn't need to) about the proper way of doing things. Using a 'real' editor I have to use 'real' code to get things done, and that's very cool.

Cheers

Dave.

[mwb1100]

I see the issue with those links. Personally, I think that Karlis should still consider this an open issue, although a low priority one as you indicate.

Sometimes you come across sites that have these massive single lines, and it would be nice to have WeBuilder be able to deal with them without slowing to a crawl. But since files with super long lines should be relatively rare and there are decent workarounds, there seems to be no urgency for Karlis or Gatis to address the issue.

[davenz]

I see the issue with those links. Personally, I think that Karlis should still consider this an open issue, although a low priority one as you indicate.

Sometimes you come across sites that have these massive single lines, and it would be nice to have WeBuilder be able to deal with them without slowing to a crawl. But since files with super long lines should be relatively rare and there are decent workarounds, there seems to be no urgency for Karlis or Gatis to address the issue.

Yep, agreed. Not high priority at all but it would be nice to know WeBuilder is able to handle anything thrown at it, stupidly or not.

Dave.

[Boofo]

I finally ran into this problem with an html file that has a javascript line that has 3,090 characters in it. When word wrap is on, the redraw of that line is really choppy. I also notice the sluggishness in editing that line, too, as has been reported here.