World: r3wp

Pekr, it looks you are not alone: http://www.google.cz/search?hl=cs&q=iacute&spell=1

You can use my script http://box.lebeda.ws/~hmm/rebol/htmlentities_latest.r
to convert it into UTF8

probe HTMLentities/decode "Základní informace "

(but now when I see it here, it's not enough as the á char is not 
converted to utf8)

Graham: I could spawn another process but have had problems with 
both using 'call to launch a second Rebol process on Mac OS X; any 
console output from the spawned Rebol session is sent to the browser 
in addition to the output it should receive from the cgi process.

It would be much cleaner for me to be able to flush the output back 
to the browser and then do my housekeeping.

And if you called a shell script that ran the rebol process?

I tried to find such a "flush" mechanism for REBOL.org (running Apache 
under a generic GNU/Linux OS).

It would have been very useful (still would be).......But I never 
found anything that worked.

Sadly, even if you call a shell script that runs the rebol process 
:-(

Not tested, but might work for flushing CGI data : close system/ports/output

Thanks for the tip Doc; I'll try it and report back.

I'm now not sure if flushing the html to the borwser is necessry. 
I tried with a simple test. Firefox displayed the page immediately 
but the connection to the server was kept open. Safari didn't display 
the page unitl the connection to the server was closed.


I dug a lttle deeper into Apache Docs and it seems that Apache doesn't 
buffer simple html output.


It seems that the "problem" is getting the browser to display the 
html before the connection to the server is closed.

I've had this same problem before implementing custom-purpose web 
apps. http being connection based, i think most clients expect the 
connection to be closed.

the client reply port anyways.

Then, you can try with HTTP chunked encoding (http://en.wikipedia.org/wiki/Chunked_transfer_encoding), 
it's the classic way to stream HTML to the browser. Having the page 
displayed while downloading chunks is browser specific. It's implemented 
in Cheyenne's HTTPd, but reading that wikipedia page makes me wonder 
if it still works with the new automatic HTTP compression introduced 
in 0.9.19 (haven't done regression tests for that case).

Thanks, Doc. I look into that.

is IE7 svg capable?

This says no -- but 3party support is possible:
http://wiki.svg.org/Internet_Explorer

thanks for the link... so no svg on my new site... darn.

Forms: How do you make forms for web-pages? Do you use any "tools" 
or just hand-code them?

And, is there a REBOL version for something like PHPMailer?

With QM, I use QuickTags (integrated into RSP or standalone) to build 
the form elements, and then wrap common constructs in functions.for 
data-driven forms.  It's not as pure as say, Henrik's HTML dialect, 
but perhaps has the flexibility of being at markup level.

http://www.ross-gill.com/page/QuickTags


Alternatively I have a make-doc dialect (somewhat rough) that I use 
for forms on my site wiki.

http://2008.rebolconf.info/on/!Edit_Form?format=raw

Is QM integrated into RSP pages? I think I need to take a closer 
look (and hope I will get it).

I'm trying to find out what's the "best practice" process for forms 
is. But after a bit of research I think it's: Do it by hand. Forms 
are not very complicated. All the generators, tools etc. are quite 
limited when it comes how to process a form. I use MooTools as AJAK 
lib and it has some very nice validator things.

No, QM has it's own separate RSP implementation.

One question towards webdesign aproach. I need to red one site. I 
want to make it based upon CSS of course. Now I can see, that some 
sites use completly table-free design, simply one long html, where 
CSS takes care of the final placement. OTOH some other sites do use 
tables at least for some basic page division (columns, sections). 
Which aproach do you suggest? What will in the long turn make my 
life easier, e.g. if change is needed? To adapt CSS, or to add cell 
to table, adding some column plus CSS?

I don't know what it is about doing table-free designs, but I personally 
think it's damn hard to do. You have some parameters that you can 
adjust for CSS that are cryptic and difficult to guess how the layout 
will be. With a table, you have cells, adjustment, width and many 
predictable elements. I think it's because CSS is underpowered for 
what it's meant to do, and the ability to separate design from content 
(desktop vs. phones) is a tad overrated, if it just makes site design 
and construction that much harder.

Agreed with Henrik.  If you aren't expecting the site to be on mulitple 
end-user hardware platforms and not expecting drastic user customizable 
styles, I don't see the need to avoid tables for the layout.  CSS 
just for the fine-tuning.

thanks. I can see e.g. big portals like  our local http://www.idnes.cz
using almost plain CSS. I noticed it on my cell phone, when FUP applied. 
The html is one long page, which then gets distributed around the 
site upon the CSS, once it is loaded ....

There have been close to holy wars between the CSS purists and those 
who use tables for everything. The best position is one that balances 
the needs and priorities of your website and development team's aptitudes.

Here'ssome arguments for as few tables as possible for layout purposes 
(it's taken for granted that tables are good for tabular data):

http://www.chromaticsites.com/blog/13-reasons-why-css-is-superior-to-tables-in-website-design/

thanks ....

Of all these points, perhaps accessability is the only valid reason 
for not using tables. If you know how to use CSS and DIVs to produce 
table-like results, fine. But it's ridiculous to assume that CSS/DIVs 
are the main bandwidth hogs for webpages. Sorry, not buying that.

sorry: "But it's ridiculous to assume that CSS/DIVs are the main 
bandwidth hogs for webpages.", should be: "But it's ridiculous to 
assume that tables are more of a bandwidth hog than CSS/DIVs for 
webpages."

Depends to what degree you use html to define visual aspects.  The 
comparison above is talking old school page design where your markup 
contains all the bgcolors, widths, font colours, etc. (FrontPage-esque) 
 Typically this approach does significantly increase page size.  
Using tables mainly as an alternative to <div> as a way to divide 
up page components in an otherwise CSS driven design isn't going 
to be at all costly in comparison.  Actual bandwidth cost I guess 
is case specific.

I'd possibly consider myself a CSS 'purist' - I like that it encourages 
a language oriented approach to page/site design (not a language 
of Rebol's calibre, indeed, but a nod in that direction : )   The 
trade off can be in the complexity in implementing layout, but really 
there are few patterns that have not been mapped out.

I use tables to presend data that belongs into tables and where it 
makes sense. I didn't use tables for general layout in a long time. 
I am not any purist but I find other ways much better than tables 
for this. It can make quite messy code and they don't degrade well 
to smaller screens.. etc..

basically tables don't presend the "information structure" of the 
site well, that is why they don't degrade well, cause problems to 
screen readers.. etc

I'll go with table free design for layout. I talked to few ppl and 
most don't use table for layout anymore ...

http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/

the web is a good distibution system... its just about all it really 
does pefectly... and that's the only thing it was designed to do.


I don't agree that web programming itself is easier, unless you really 
are doing easy apps.  


IMHO Rich clients are the best of both worlds combined into one seamless 
experience

I use mix of tables and CSS for layouts:) I don't remember exact 
cases now, but I had problems to do some layouts with just CSS (working 
not just in one browser).

There's also a page at 37signals.com advocating for web-based software 
: http://37signals.com/webbased

One of the advantage listed is : "You’ll never have to ask “Is it 
compatible?”"...good joke:-)

Curiously I find you have to ask that quite often. Still so many 
IE users around.

welll all browsers render stuff differently, chrome FF and safari 
included.

few different pixels here or there never mind :-)

Any one looked at webkit, code-wise?  I mean, using, has used, tried 
to use it, participating in it, anything.

http://webkit.org/

(webkit is the engine powering chrome and safari, if you wonder)

On OSX you can use like every other library. Fully available via 
objective-c interface.

Interesting pov onto website creation - http://24ways.org/2009/make-your-mockup-in-markup

I don't get it... I've always built websites like that. Using a paint 
program to do it is just impossible. :-)