World: r3wp

REBOL's POST , GET etc really need re-working -- for an IT aware 
language posting to websites id ridicoulously hard

is*

charles, welcome to reality !  In theory rebol supports many protocols 
but in practice the support is incomplete and it has been incomplete 
for a long time. check rebol.org, there are several patches for cookies 
support

I wrote http-tools, but haven't used it for years.

you normally need to send the cookie each time ... that's what browsers 
do

yes, I am sending it each time, but for some reason it seems to only 
like the first request, after that it expires , or something else 
is going wrong ... Id really like to see a client with transparent 
support for cookies

are you getting a redirect from the second page ... that is followed 
without the cookie

oldes did something on transparent support ..

so did I .. but that was long ago.

Yes, I did, and if you scroll a little bit up, you can find the link 
easilly - it's in big yellow block of text:) And I agree, that it 
would be good to have cookies support directly in Rebol, as my cookies-daemon 
is relly hard hack I cannot be sure that it would not rewrite some 
future http protocol updates

Has anyone tried to solve at least some basic anti-spam form protection? 
I mean - those numbers/letters you have to rewrite to your form field, 
in order to be processed? Will it work with rebface at least, if 
my Linux server has no X-Win installed?

I want to do some small post-card system for my friend. He can't 
program much and adapted small php solution, but that solution is 
so basic, that it even does not randomize postcard number in presented 
link ... so you can cange your url and get access to someone's else 
message. That is imo unacceptable.

What I really like is www.view-card.com system. It is able to embedd 
images directly into email's body (not an attachement), but I found 
out, that most freemails has html email displaying turned off by 
default ....

had anyone done an email address validation according to rfc 2822? 
Well, I mean email adress part? Our to-email "whatever-stupidity-you-write-here423423423-rebol-considers-being-an-meail@{{}}}]//" 
is kind of funny :-)

I thought datatypes should be usefull, and there is exactly precise 
description of what is, and what is not email, so how Rebol can simplify 
it so much?

Not quite an email address validator, but the REBOL.org uses an email 
address spotter [contributed by Andrew Martin] to find and obsfucate 
email addresses in ML messages, etc.

You could use the same basic parse patterns to identify / validate 
email addresses. 

I haven't checked RFC 822 in detail, so it is likely that Andrew's 
code is more liberal than the actual spec, but it could be a starter.
Would you like a copy of the function?

yes, of course ... you can send it to my mail address, or point me 
to some link ...

thanks a lot :-)

I wrote an email validator .. which works by doing an smtp challenge.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=email-check.r

it's probably a reason why my spam has increased on gmail :(

Note to Sunada ...  licence (english) and license (american) spellings 
appear on the same page :)

graham, you really should remove the addresses from there, especially 
those which are rebol.com related....

You don't see them unless you're logged in!

As Graham says, the addresses are munged on REBOL.org unless you 
are a logged-on member of the Library. That doesn't stop a spammer 
grabbing them, but it does reduce the risk considerably.
**
Thanks for the spelling correction!

I (finally) got around to fixing the license/licence typos. Thanks 
again Graham.

If you spot any other typos on REBOL.org, please report them in the 
Library group.
***

Incidently, I tend to use US english for webpages and British english 
for program code (variables, comments etc), so my code is littered 
with duplicate spellings: color/colour etc,

Hi,

I need another short advice :-)

do you prefer:


- directly accessible menu menu: http://www.creactive.cz/work/xidys/online/

or


- initially collapsed menu: http://www.creactive.cz/work/xidys/xidys_web_hp.jpg

   - with mouse-over effect: http://www.creactive.cz/work/xidys/xidys_web_hp2.jpg

   - and after clicking an item: http://www.creactive.cz/work/xidys/xidys_web_sec.jpg

(dis)advantages to both:


According to company working on our website, there is something like 
slight barrier, when user needs to click, and wait where the click 
does take him/her. According to them, users prefer scrolling. OTOH 
the menu can get long, and e.g. e-shop direct icon is not visible 
(nor is last section), and there is no easy other place, where to 
put such an icon (direct link).

thanks a lot :-)
-pekr-

Have you seen, what Jakob Nielsen say about menus?
http://www.useit.com/alertbox/20011209.html
http://www.useit.com/alertbox/20001112.html

There are many good advise in his alertbox: http://www.useit.com/alertbox/

ok, thanks for links!

I definitely prefer all the info being visible on the page.

Expecting people to play hide and seek is good in games and some 
styles of websites. But if you are trying to make your site (and 
therefore your company's information) easily available, then don't 
hide links in any way.

OK ... what about the screen height problem? More so with new wide-screen 
LCDs? It is like 800pixels, minus Start bar, minus browser (app bar 
+ menu + toolbar + tabs), which usually lets you with something like 
500 - 600 pixels ... not all those menu will be visible then ... 
but ppl can scroll :-)

I prefere the directly accessible menu as well

ok, so far that seems to be option of circa 60% of ppl I asked :-) 
40% prefer partially collapsed aproach, and noone prefers pop-up 
menus :-)

No who says VID is missing menu? :-)

I expect, you will have some content on the page as well... so you 
will have to scroll down anyway.

The usual situation with limited screen height is to put all the 
vital stuff "above the fold" (it'sa  metaphor from the days of broadsheet 
newspapers)....The crucial stuff should be visible without scrolling 
(or mousing or hovering).

Yes, but then menu is too deep to be visible - and what in menu is, 
and what is not, - crucial :-)

or you can use mixed approach... if you are in some content section 
let only this section menu to be opened by default

but anyway.. in this case I would prefere the page you already have

It's trade-offs Petr!

Dropdown/pullout menus take less screen space but need more clicks, 
and may be less accessible.

Too many visible options on one screen make it difficult too see 
the important links.
Its not easy to get the balance right on the first try.

That's why usability testing is needed, and why usability consultants 
can make a good living.

Pekr, I prefer the expanded menu, immediately available. I don't 
care if it's two or three pages long. If the section titles are bolded 
(eg. "Internet a site", "Kiosky" etc.) and obvious, then reading 
them while scrolling down the page is no problem. And I think your 
search bar should go at the top, to solve the problem of being too 
far down to be visible initially.

OK, thanks for the input ... searbar will be probably removed ... 
there will not be enough content to search imo ....

I prefer direct e-shop link

later, if needed, it could be added to the top-right bar of the site 
....

yes, good position.

Max - re templating. Yes, I use "code", actually not code, just markers 
like <font face="Arial" size="2"><!--name-->ne<!--end--></font></td>

simply put, there is following workflow, similar to how Gabriele's 
Temple worked:

- browser requests page
- webservers takes .html
- then it sees, .html should go via some handler
- handler is called - so e.g. index.html is passed to pekr-rsp.r

- pekr-rsp.r, to save some processing time (prevent parsing), looks 
if .html page is registered as dynamic, non-dynamic .html is returned 
directly to browser - non-measurable slow-down

- if page is supposed to be dynamic, it is being parsed. It looks 
for marked sections and particular handlers are called, which know, 
how to treat that section

so, we can start with static page. Then we slowly turn it to dynamic. 
All my gfx man has to do is to later add some markers there. RSP 
ruins that aproach imo.

in order to work, I don't want my gfx man to play with any rebol/php 
code on his side ....

my aproach has some disadvantages too, e.g. remark can compose subpages, 
so you don't need e.g. to repeat footers, headers, etc.