Forum Moderators: phranque
<style type="text/css">
.noborder { width: 100%; border:none; }
</style>
........
<form action="">
<textarea class="noborder" cols="75" rows="50"></textarea>
</form>
Like that?
Problem is, borders are there for a reason . . . that example only works because it's 100% width and anywhere you type is "textarea." Also I'm presuming you'd want to save this somehow, so you might have to do an auto submit with Javascript . . . then could use perl, php, asp, whatever to write it to a database.
[edited by: phranque at 10:42 am (utc) on June 10, 2009]
[edit reason] "spliced" from crosspost [/edit]
sort of like they are just writing on the page.
It doesn't have to look or feel like a form, but, insofar as data is edited locally and submitted, in practice, it must act like a form.
Kaled.
Kaled: I would like users to be able to upload thier own content as well as edit other's content. It would be great if users had the option to change text size, font and color too, but i guess that would require the use of a client side wordprocessor? I would like to get away from having like a pop-up word processing application though. I guess the basic idea would be like a paint program.
Could you put that into laypersons words?
I think so....
1. You're typing into a web form object, styled as you wish, lets say its a kind of multiline text box.
2. Everytime a key is pressed while you type, a Javascript event is triggered called onkeypress [w3schools.com].
3. You could intercept that keypress and send it off to your backend database invisibly (AJAX uses mechanisms like this - basically you have javascript doing POST's to a database webapp URL in the background.
If I understand the problem correctly (you want to build a system similar to Google Docs), then this type of AJAX might be a possible solution.
The other way to approach this is exactly as Google Docs have. Have a look at the way Google Docs does an "auto-save" when you're typing a document. This, instead of using a keypress intercept, has a timer that periodically sends what you've typed off to the server.
Both solutions do have scaling implications - you'll be hammering the webserver quite a bit.
If that doesn't make sense it's possible I've misunderstood the problem.
Could you explain why a wiki CMS couldn't accomplish what you're after?
With a background javascript timer periodically calling post without directing the response of the POST back to the page in view (eg standard AJAX type mechanisms), I think it probably could.
If you're using HTML then those text input fields would be wrapped in a <form> for processing. You can't escape that.
You can to an extent. You can use Javascript to extract data entered into those items, and you can also use Javascript to redirect the form's action URL dynamically, which would mean you could have, for example, an AJAX based submission system (going to one webapp URL) and still keep the button if you wanted to (going to another webapp URL).
What I want to do is have users be able to post on a page with out completing a form. At least not a form that they can see... sort of like they are just writing on the page.
If a "SAVE" button is allowed in your context (eg, like Google Docs) then AJAX will let you do this without the user navigating to a different page (browser remains static).
If a "SAVE" button is not allowed in your context then you'll need to intercept keypresses with Javascript and save one character at a time (or buffer it and save, eg, 10 characters at a time). Or do the Google Docs auto-save trick and do this with a timer. This latter one comes with some risk that the user browses away, or goes offline, before the timer has activated and causing some data loss.
To take a slightly different approach to this discussion - could you explain in what ways your system (purely in terms of input from the user) needs to differ from Google Docs ?
I guess the basic idea would be like a paint program.
Like this [imaginationcubed.com]?
This is a bit more complex . . . requires a few combined technologies . . .