Better Browsers for Text & Form Handling? 65
Dan Warne asks: "I work as a web content administrator for one of the big newspapers in Australia. The front end of our content manager is browser-form based. Yet browsers all have horrible text editing features; neither Mozilla nor IE support search-and-replace, something desperately needed for anyone who works with a lot of form content. Aside from using a standalone text editor, what software out there provides a better browser-based solution for people who work with text in web forms a lot?"
Pick Up a Book... (Score:2, Interesting)
Re:Pick Up a Book... (Score:2)
In fact, If you pay me, I'll even write it for you. Like other people in IT, I'd stand on my head for money at this point.
Good luck!
Re:Pick Up a Book... (Score:2, Interesting)
lynx! (Score:4, Interesting)
Right now, I'm writing this with `vim`, having hit ^Xe in the textbox that `lynx` opened up. I have all the unimaginable power of vim at my disposal. :)
Re:lynx! (Score:2, Interesting)
Wait a second - we're supposed to be the crippled text-mode guys, how come we're the ones who are laughing?
YAW.
Re:lynx! (Score:1)
The obvious segue to that is to send an OOo doc... (Score:2)
We can do that right now by adding the OOo doc as a frame and leaving a form with an "upload" button in another frame, but that's kind of clumsy. With KDE 3.2 and KOffice 1.3 (stably by 1.4, I expect), OOo docs will be embeddable as KParts so it should in theory be simple enough to integrate that, maybe a frame with "save" and "revert" buttons on it and another with the doc itself.
Re:lynx! (Score:1)
Yes, UNIX folks know how to handle god like powers. DS wants a pretty GUI!
Re:lynx! (Score:1)
w3m / vimpart (Score:3, Interesting)
I also have high hopes for someday being able to use vimpart [freehackers.org] as a textarea editor in Konqueror - that alone would get me to switch over from Moz.
w3m rocks. (Score:2, Informative)
- Although it's console based, it can display images. This is a really neat trick. It's actually using X11 to overlay images on the console. It even works when w3m is in a remote terminal, as long as X11 is forwarded back.
- It supports tabbed browsing.
- SSL support
- It supports tables and
Re:w3m / vimpart (Score:2, Informative)
Even if there is no inbuilt way of doing this, you can do it all
Applets (Score:2, Interesting)
Disappointment (Score:2)
Sadly, I just tried it and I cannot. Is this really such a difficult feature to implement, or has nobody really brought it up before now? Certainly in my years of using a browser I've not needed this feature (otherwise I would have known that Opera doesn't do it) -- but now that I know the feature is lacking, I want it.
fast development (Score:1)
Re:Disappointment (Score:2)
but the thing is that maybe nobody just thought that you would actually use the browser for editing articles(without having plugins, applets or whatnots ). for posting them, sure. but i'm pretty sure they'd have more dandy time writing the articles in a real
Welcome to the internet, we have lots of stuff... (Score:2)
searching and replacing (Score:1)
find / -iname index.html
grep -e "stuff to find"
replacing:
sed -e "s/one/two/" index.html >newindex.html
Plugin for Mozilla (Score:2)
FCKeditor (Score:2, Interesting)
FCKeditor [fredck.com]
vi in mozilla (Score:1)
Anyone else remember seeing this? Perhaps it was someones wish-feature, as I can't seem to find anything about it on google
Re:vi in mozilla (Score:1)
Bad slashcode for removing anything in square brackets when in 'Plain Old Text' mode, hrmpf!
The punctuation nazi *HITS*! (Score:1, Redundant)
< > Brokets or angle brackets (type < >)
[ ] Brackets or square brackets
{ } Braces or curly brackets
&laqou; » Guillemet, angle quotes or chevron brackets (real ones thoughtfully ripped by slash)
I'm betting that you used brokets, as in <TEXTAREA>, but without escaping them, yes?
Re:vi in mozilla (Score:2)
OmniWeb (Score:3, Interesting)
It's MacOSX only though, of course, if you're working in the print industry getting a mac to run it on shouldn't be too hard.
Re:OmniWeb (Score:1)
AMEN, Preech on... (Score:2)
So, I have to enter data again, and again. Text input has always been a problem on browser. I have some applications that auto-fill, but things like "date" should be autofilled.
A browser with advanced text input features, would really be useful.
Re:AMEN, Preech on... (Score:2)
At least, that's a thought for right now to deal with it.
Why do the editting in a TEXTAREA? (Score:1)
YAW.
Re:Why do the editting in a TEXTAREA? (Score:2)
Browsers are for browsing.
Let content writers use a real editor!
Editors exist. You don't have to invent them.
Re:Why do the editting in a TEXTAREA? (Score:1)
vi wrong approach for this? (Score:3, Insightful)
Don't get me wrong, I love vim. However... most of the suggestions here have been along the lines of "vi in a browser" type ideas. This is excellent for power users, but might not suitable for the newspaper staff in question to do their content editing
vi (and emacs) have more wonderful features than almost anyone would ever use, but the learning curve that comes with this can be intimidating for some. Are the people who will be using this system tech types, or journalists? If the latter, they probably won't think that ":%s/Linux/GNU\/Linux/g" is quite as intuitive as a dialog box with boxes labelled "Find" and "Replace with".
Depending on the proficiency of the intended users, they may well be better off with some kind of plugin / applet / whatever that resembles Wordpad than trying to master an editor with hundreds of not-so-intuitive keystrokes and commands.
Re:vi wrong approach for this? (Score:2)
That depends also on how often you need new users. If the form is used only by a few staff reporters, training them to use vi isn't particulary hard, it just takes some time. If the form will be used by hundreds or thousands of people, many who only use it once, then teaching vi isn't worth it.
The people who use it over and over again may (or may not) come to love vi once they learn the power features without leaving the keyboard.
Re:vi wrong approach for this? (Score:1)
I think its only the ones who believe that the machine should do the work. Some are Luddites, and don't want the machine to do their work. Me I love automating tasks. Automation is better than hiring headcounts, they work nights and weekends, do what you say, and don't call in sick.
: % ! perl 's/ (\d+) (\d+) / (($1) - ($2)) /e'
Try that with vim inside a file of the output of "gdf -k".
Re:vi wrong approach for this? (Score:1)
If you don't like java then maybe... (Score:2, Informative)
Of course, there's no linux support (yet) for shockwave and I'm probably a bit biased since I've been doing shockwave work for 3 years straight.
Tried Firebird? (Score:4, Informative)
Then you can easily associate external editors for textareas. If that doesn't suit your needs you could always write your own extension. (It's pretty easy, I wrote my first one, Image Zoomer [mozdev.org], in about 2 days last week.)
Do it again! (Score:2)
Re:Do it again! (Score:2)
Doesn't do find/replace but it's well written and a snap to modify if you know a little J/S.
tar! (Score:2)
Pet Peve... (Score:2)
Re:Pet Peve... (Score:1)
Mozilla extensions (Score:2, Informative)
Consider:
Electrix [reddleman.org] -- not developed anymore, but still functional. From its site: "To edit the text in a textarea, hit Ctrl-e. The editor you set up will appear. Once you exit the editor, Electrix will write the changes back to the textarea."
Or htmlArea [interactivetools.com] -- this works within browser and suports IE beside Mozilla; but of course you don't want users to use it, aren't you?
Re:Mozilla extensions (Score:3, Informative)
Blogger [style] interface? (Score:2)
Movabletype.org says they support "Blogger and MetaWeblog XML-RPC APIs".
disclaimer: I'm an XML-RPC fan, but have NO experience with blog servers or clients.
External Editors (Score:2, Informative)
It uses a helper application within your browser to edit text in the editor of your choice.
Even if you are not using Zope I am sure you could adapt this to other app servers.
Also WebDav provides complementary facilities and is available from within ie on the client WebAdmin [cpg.com]. This approach will require that your server speaks webdav too.
The reality of the situation (Score:2, Informative)
Thanks everyone for the suggestions, especially those people who suggested Mozilla Plugins as a solution. (I had previously searched for these without much luck).
I agree totally that web browsers are an inappropriate front-end for content management and editing, but you've got to work with what you've got. Unfortunately a lot of content management systems do use a web front end.
Take HTML as an analogous example. It was never designed for precise page design and layout, but more for structuring content r
Front-end replacement? (Score:2)
I realise that most WCMS programs use web forms, but have you considered looking into how difficult it'd be to swap out the front end? Have you contacted the vendor of the software? Perhaps they have some suggestions?
A lot of WCMS vendors work on collaborative systems, so if there were some way to integrate with Macromedia's system (Contribute) or else some other interface that perhaps modifies the browser either via plug-in or proprietary interface (since you're on Wintel), that might be the best way to g
Rich-Text Editing in Mozilla/IE (Score:4, Informative)
You'll need to add some additional code to allow for features such as search & replace, but all that'd take is a few lines of ECMAScript/javascript...
Re:Rich-Text Editing in Mozilla/IE (Score:1)
Some alternative editors:
- mozile [mozdev.org] - xhtml editing for mozilla.
- Bitflux Editor [bitfluxeditor.org] - Wysiwyg XML Editing for Mozilla (based on mozile and yes, this is a shameless plug
- Xopus [xopus.org] - Wysiwyg XML Editing for MSIE/Win (commercial product...)
Check out ektron (Score:1)
We use Ektron's eWebEditPro, which has an XML-based customization scheme. You can allow users to post HTML, or simply allow them to do some more advanced things w/ plain text.
Konqueror will have it! (Score:3, Informative)
How about htmlarea (Score:1)
The real funky thing about this one is that there are spell checker and tables modules available for it.
Re:How about htmlarea (Score:1)
ok it doesn't omit " with attributes and seems to create clean code after a few quick tests - but it still uses the font tag, which is deprecated in HTML 4 and not in the XHTML specs.
Besides that it should already support stylesheets. Like using MS-Word you create a style for a paragraph, headline or whatever and re-use the same style for all repeating instances of these page-elements. The advantages using CSS would be - People know how it works to define styles in Word, they can change the style of the
Re:How about htmlarea (Score:1)
That's funny, because I just followed the link, opened up the editor to test, and found it does fonts through inline style sheets (like in a span tag)
Emacs/w3 (Score:1)
better built-in text editor than Emacs/w3. It's fully extensible,
fully scriptable, and closer to fully featured than any other editor
available today. The more advanced features do have a learning curve,
but what fully-featured thing doesn't?
Better Xemacs/w3 (Score:2)
Safari! (Score:1)