Home
The Toolkit for Online Communities
17705 Community Members, 0 members online, 3986 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : HTMLarea and ad_form/form builder

Forum OpenACS Development: HTMLarea and ad_form/form builder

Icon of envelope Request notifications

Collapse
Posted by C. R. Oldham on
Greetings,

I am quite enamored with HTMLarea (http://www.dynarch.com/htmlarea/).  I'm trying to incorporate support for it into ad_form/form builder.

The area where I'm stuck is that if you are going to use an HTMLarea on a page, then there is a chunk of javascript that needs to be included at the top of the page.  This chunk needs to be included only once (even if I had multiple HTMLareas).  Ideally simply the call to ad_form and the corresponding formtemplate tag in the adp should be sufficient to get this chunk embedded in the target page, but I'm not sure where to look to make this happen.  I found the formtemplate proc in acs-templating/tcl/tag-init.tcl...suggestions appreciated.

Collapse
Posted by Don Baccus on
CR, if you'll e-mail me a reminder I'll dig out some javascript widgets we did for Greenpeace that only emits the necessary javascript once and only if you use the widget.  This should help you figure out how to get HTMLarea working.

I've looked recently at a WYSIWYG textarea package using javascript that supposedly works with standard Javascript, I should track it down to see if it might be a better alternative (i.e. has a chance of working with Safari or Opera as both of those are maturing in their Javascript support).

It would be great to have such a widget for content management  style applications ...

Collapse
Posted by C. R. Oldham on
Don,

Thanks.

I was able to add this and make it work for IE, but not Mozilla.  Mozilla is a lot more strict about where the JavaScript definitions have to be.  I'm pretty sure that this can't work unless there is support in the master template for the page, since for Mozilla the javascript declarations seem to need to be in the header and the initialization function needs to be called from the body's onLoad handler.

That's all fine if we can guarantee that header_stuff and the attribute multiple are present in the master template.  We'll run into other problems, however, if a page with an ad_form also requires an onLoad handler.

Collapse
Posted by C. R. Oldham on
OK, I'm stuck.

I figured all it would take would be to append the javascript includes to the header_stuff variable with

upvar #$level header_stuff header
append header "javascript stuff"

but that doesn't work.  Am I confused about which stack level we are at when rendering the form?  This is in packages/acs-templating/tcl/form-procs.tcl.

Thanks.
--cro

Collapse
Posted by Don Baccus on
Maybe our master template needs a "javascript" property which, if not blank, gets put out appropriately?
Collapse
Posted by C. R. Oldham on
Sounds like a good idea.  I attempted to implement this, but I think I am stuck in upvar hell. :-)
Collapse
Posted by Randy O'Meara on
CR, [something like] this should work:

in your.tcl:
    set js {
        ...put your javascript code here...
    }

in your.adp:
    <master>
    <property name="header_stuff">
        <if @header_stuff@ defined>
            @header_stuff;noquote@
        </if>
        @js;noquote@
    </property>

Or, you could put your javascript directly in your.adp where @js@ appears. BTW, this is how you would add css <link...> references also.

Randy

Collapse
Posted by Rodrigo Proença on
C.R. This work for me:

in dotlrn-master.tcl add
# HTML AREA
if { ![template::util::is_nil htmlarea] } {
  set header_stuff "
  $header_stuff
    <script type=\"text/javascript\" src=\"/resources/dotlrn/htmlarea/htmlarea.js\"></script>
    <script type=\"text/javascript\" src=\"/resources/dotlrn/htmlarea/dialog.js\"></script>
    <script type=\"text/javascript\" src=\"/resources/dotlrn/htmlarea/lang/en.js\"></script>
    <script type=\"text/javascript\">
        var editor = null;
        function initEditor() {
          editor = new HTMLArea(\"$htmlarea\");
          editor.generate();
      }
    </script>"
  template::multirow append \
  attribute onload "initEditor()"
}

call in your adp pages:

<master>

<property name="title">@instance_name@</property>
<property name="context">@context;noquote@</property>
<property name="htmlarea">text_area_name</property>

<form name=edit method=post action=content-update>
<textarea id="text_area_name" name=content rows=30 cols=60 wrap=soft>@content;noquote@</textarea>
<input type=submit value=save>

</form>

Collapse
Posted by Lars Pind on
I looked at this today, and it's not that hard. I have the basics worked out now, just need to make sure everything's smooth, clean, and nice.

Laides and gentlemen, we will have a WYSIWYG editor for 5.1, for both IE and Mozilla.

Had I known it was this easy, I'd have done it ages ago.

/Lars

Collapse
Posted by C. R. Oldham on
You are awesome Lars.  This is a major step for the toolkit, IMHO.
Collapse
Posted by Cathy Sarisky on
Awesome, Lars.

Rodrigo, thank you!  I've been fighting with getting HTMLArea 3 to work, and was missing the

  template::multirow append \
  attribute onload "initEditor()"

code snippet.

Collapse
Posted by Caroline Meeks on
This sounds great! Has anyone gotten this working with ETP yet? What do I need to upgrade?

Thanks

Collapse
Posted by Lars Pind on
I'm working on making it part of richtext, so all forms currently using richtext will have access to this.

That was actual part of the original intention of the richtext widget and format, that whenever we'd get a wysiwyg solution, we'd integrate that into the richtext widget.

/Lars

Collapse
Posted by Rocael Hernández Rizzardini on
This is great Lars, this is a major contribution for the end-users, more bigger that we might imagine. Please let us know when that is commited into the CVS.
Collapse
Posted by David Cotter on
Caroline,

To quickly get it working with ETP this is what I did. There's probably a more elegant way to do it:

http://openacs.org/forums/message-view?message_id=115599

Collapse
Posted by C. R. Oldham on
Lars,

Is this backportable to 5.0, or does it depend on new 5.1 features?

Collapse
Posted by Lars Pind on
Not sure yet. I'll know more once I've finalized and committed.

/Lars

Collapse
Posted by Caroline Meeks on
Does HTMLarea work well for Mac OSX with IE?
Collapse
Posted by Malte Sussdorff on
For security reasons I'd not use the IE on OS X. It is old, not maintained and most likely full of holes and bugs.
Collapse
Posted by Mark Aufflick on
and annoying out of date root certificates.
Collapse
Posted by Walter Smith on
FYI, HTMLArea version 3 does NOT work on IE with OS X (version 2 didn't work on the Mac at all).  It works well with Mozilla, however.  I have some clients who are using it on Macs, and I just make sure they all have Mozilla.

Note that it is best to turn off the "Use CSS styles instead of HTML elements and attributes" preference, under the Composer section of Edit Preferences for Mozilla.  Otherwise you get some pretty far out style-based HTML tags that confuse other editors (and sometimes Mozilla itself).

Collapse
Posted by Lars Pind on
htmlArea 3 has been committed to HTML.

The htmlarea stuff itself sits in acs-templating/www/resources/htmlarea.

There's a acs-templating parameter, UseHtmlAreaForRichtextP, which controls whether richtext widgets use the htmlArea.

This parameter defaults to 0 (off), because we don't yet have a feature that lets the user choose to turn off htmlArea, or switch between htmlArea and normal textarea input, and htmlArea doesn't work on all browsers.

For more documentation, see template::widget::richtext.

This is on HEAD, meaning 5.1.

For those interested in back-porting, there's also a change in acs-subsite/www/resources/core.js, and to www/blank-master.tcl/adp.

/Lars

Collapse
Posted by Guan Yang on
How about an online demo?
Collapse
Posted by C. R. Oldham on
Lars,

Can you give a brief overview of what it might take to retrofit an ad_form to use htmlarea in the textarea instead of the standard textarea widget?  I played with this last night and it didn't work quite right.

I was trying to get the HTML textareas in mailing-lists to use HTMLarea.  In packages/mailing-lists/www/madmin/classes.tcl I changed each ad_form field that I wanted to use HTMLarea to look something like

{html_body:richtext(richtext),optional {label "Default HTML Body"} {html {rows 12 cols 80}}}

but I've noticed that when there are three HTMLareas on the page only the last one actually updates the content.

Suggestions?

Also, does fullscreen mode not work?

Collapse
Posted by Don Baccus on
How about a flag to the richtext widget to allow control on a per-form basis?

The global flag's good, of course ...

Collapse
Posted by Lars Pind on
The flag is already there. See doc for the proc :)

/Lars

Collapse
Posted by Walter Smith on
Does anyone have this working in 5.0.3?  I'm trying to back-port, which seems pretty straightforward, but I can't get htmlArea to show up.

I'm trying to use it with ETP, and I've gotten to the point where it's including the references to the htmlArea JavaScript and CSS files.  So I know I have it at least partially set up.  However, it still displays a plain textarea input.

I've copied and/or made the changes to the richtext procs, acs-subsite/www/resources/core.js and to www/blank-master.tcl/adp, and I've set up the UseHtmlAreaForRichtextP parameter.  Anything I could be missing?

Collapse
Posted by Walter Smith on
I too have been working on the retro-fit for using htmlArea with Mailing Lists, and I've run into the same problem.  It only picks up and saves input from the last htmlArea on the form.

Have you made any progress C.R.?  I'll post back if I figure anything out.

Collapse
Posted by C. R. Oldham on
I've learned a lot.  I'm still stuck in a few areas though.

To begin with, it's worth mentioning that with ad_form, a richtext widget (HTMLarea or the old richtext) is not the same thing as a simple tcl variable.  A richtext widget presents a two-element list (I think)--the first element is the actual text, and the second element is the content type (always text/html in this case).  So when you are going to expose some value you have to code it as a list or what happens is ad_form only shows the first word (because it sees that as the first list element).

This means you have to massage the stuff that comes in and goes out to the database.  I hacked it and just said

set html_body [list $html_body]

because I couldn't figure out the right syntax for the accessor functions for the richtext widget.  That's for loading the content into the form.  For saving the content from the form, fortunately Malte gave us a well-designed mailing-list api, and it was easy to add "template::util::richtext::get_property contents $html_body" to the right places.

Secondly, I punted and only used HTMLarea for the html_body portion of the mailing list.  I figured that the header and footer would be small enough that you could hand-code them, or skip them all together.

I think I've just about got this all fixed using just one HTMLarea.  Do you want patches?

Collapse
Posted by Walter Smith on
Thanks C.R.  That helps a lot, and I would love the patches.

Also, I believe I just resolved the issue with multiple htmlAreas.  I found the fix on the InteractiveTools.com forum.

1) In blank-master.adp, add this line *above* the other htmlArea JavaScript includes:

  <script type="text/javascript" language="JavaScript">_editor_url = "/resources/acs-templating/htmlarea/";</script>

2) Download the latest version of htmlarea.js from SourceForge at  http://cvs.sourceforge.net/viewcvs.py/itools-htmlarea/htmlarea/htmlarea.js  and replace the one that it came with.

That worked for me.

Collapse
Posted by C. R. Oldham on
Ah--very cool.

Was there a reason why you didn't update to the latest CVS of all of HTMLarea?

I'm filing my patches as a bug-tracker item for mailing-lists.  The diff is against the oacs-5-1 tree.  The bug-tracker item is

http://openacs.org/bugtracker/openacs/bug?bug_number=1644

Note I figured most of this out by looking at bug.tcl in the bug-tracker package.

Collapse
Posted by Walter Smith on
Thanks for posting the patches C.R.

The main reason I didn't update to the latest htmlArea from CVS is expedience (the convergence of multiple deadlines), and also that the posted fix just said to replace the one file.  However, it looks like I'm going to have to get the rest, because it broke a couple other features, such as full-screen editing, which had been working previously.

Collapse
Posted by Hamilton Chua on
I am recently trying out richtext with htmlarea. I got these errors in my logs.

[06/Apr/2004:17:15:33][32318.1086155568][-conn3-] Error: rp_sources_filter: file "/web/openacs/www/resources/acs-templating/htmlarea/htmlarea.js" does not exists trying to
serve as a normal request
[06/Apr/2004:17:15:33][32318.1087208240][-conn4-] Error: rp_sources_filter: file "/web/openacs/www/resources/acs-templating/htmlarea/lang/en.js" does not exists trying to serve as a normal request
[06/Apr/2004:17:15:33][32318.1085102896][-conn2-] Error: rp_sources_filter: file "/web/openacs/www/resources/acs-templating/htmlarea/dialog.js" does not exists trying to serve as a normal request
[06/Apr/2004:17:15:33][32318.1080175408][-conn1-] Error: rp_sources_filter: file "/web/openacs/www/resources/acs-templating/htmlarea/htmlarea.css" does not exists trying to serve as a normal request

Collapse
Posted by Lars Pind on
You need to have a directory packages/acs-templating/www/resources/htmlarea in your file system.

It looks like this directory is missing.

Are you using cvs? Did you using the -d option when updating? cvs up -d.

If not, please let us know how you got the source, so we can fix the problem.

Collapse
Posted by Hamilton Chua on
Silly me....
I did not put a -d option.

Thanks Lars.

Collapse
Posted by xx xx on
  1. I have trouble getting fullscreen mode to work (IE 6.0/win2k). I see the window popup, I see some gray, but no buttons.
  2. Can I open in fullscreen-mode by default?
The server error log shows no errors, but Javascript keeps complaining. Do others see this?
  • Before transition from Richtext to HTMLarea takes place
Line: 144
Char: 2
Error: Object doesn't support this property or method
  • When opening fullscreen mode
Line: 119
Char: 3
Error: 'HTMLarea' is undefined
Line: 150
Char: 3
Error: 'editor' is null or not an object
I'm using a simple testpage with one ad_form-element 'var:richtext(richtext) {htmlarea_p "t"}' in .tcl and formtemplate-tag and master-tag in .adp (oacs Head/5.1)
Collapse
Posted by Lars Pind on
Hi Aldert

Are you on the latest 5.1 version? Which browser?

/Lars

Collapse
Posted by xx xx on
I'm on IE 6.0.2800.1106 (win2000) and checked out oacs/.LRN "Head" on may 4th.
I don't think I need the CVS changes on HTMLarea of may 6th(browser-sniffing), do I?
Collapse
Posted by xx xx on
Same problem on 5-1 branche. This is what I do as a test.

In .ADP:
<master>
<property name="title">@page_title@</property>
<formtemplate id="html_area"></formtemplate>

In .TCL:
set page_title "Test HTMLarea"

template::form create html_area

template::element create html_area referer \
        -optional \
        -value "/" \
        -datatype text \
        -widget hidden

template::element create html_area content \
        -value "{Hello HTMLarea} text/html" \
        -datatype richtext \
        -widget richtext \
        -htmlarea_p "t"