Re: Silva 2.2b1dev-r35291: KupuPopupWindow Field

Greetings,

> >> The KupuPopupWindow Field requires javascript which is only present
> >> in
> >> the edit screen.
> >
> > why? to enlighten me, can you tell me a use case for an author to
> > have a KupuPopupWindow in the external source?
>
> The KupuPopupWindow is pretty tightly integrated with the External
> Source toolbox. But I can certainly understand (based on your use case
> below) why you'd like to have something similar.

I designed the kupupopupwindow to allow rich text entry into code sources.  
E.g. the "caption" component of the "image + caption" code source. Or -- and 
this is the first use case --  the "citation" code source in 2.2 requires 
rich text entry.  (in 2.2. the 'citation' element is deprecated).

> >>> i don't want to show the kupupopup textarea on the public view only
> >>> the kupupopup contentbox. i can probably do this with some css
> >>> (.kupupopuptextarea {display:none;}), is there any other way?
> >>
> >> I don't understand what you're trying to do. Do you want the public
> >> to
> >> use Kupu in the public view?
> >
> > yesss! i have the following use case: we have a yearly conference
> > here at the eth. people are allowed to submit a text-only abstract
> > of 300 words. until now i have used a TextAreaField. but people try
> > quite funny and strange things to "format" their input which we then
> > need to manually clean up. for the next conference i wanted to use
> > KupuPopupWindow to allow the participant to format their input and
> > spare us the manual cleanup. this would also result in nicer
> > abstract pages, booklets, etc.

In Bethel's case, we (I) usually prefer a lighter editing interface for public 
rich text entry.  We've used tinymce in a few places to a high degree of 
success.  Using tinymce, it is easy to set a class or an ID on the formulator 
textarea field you are using for rich text entry, and tinymce takes care of 
the rest.  I don't think we have any publically accessible forms with tinymce 
rich text, or I would point you to one.
>
> I wonder if we could make a Formulator field that provides a rich text/
> Kupu for a textarea.
It might be easier than that.  We just need to find the correct javascript 
files and include them on the public page.  Or, refactor the kupu-popup 
javascript code into it's own js file.
>
> >>> the second time i click on the edit button, after saving inbetween,
> >>> the selection of toolboxes made in the zmi is ignored; all are
> >>> shown.
> >
> > in the above use case this is a big problem.
>
> This is happening in your public page? There's a cookie that holds
> that info, but again I think it's integrated with the edit screen.

Kit, are you thinking of the 'collapsed' state of the toolboxes in the main 
kupu window?  The kupu popup window is configurable so that only certain 
tools and text styles can be exposed to the author.  This allows you some 
control over what is entered in kupu.  This isn't a silver bullet, as the 
controls are just hidden -- it's still possible to edit the source (if that 
button is enabled) and put in what you want.

It is true that version 1 of the KPW is limited to just the original 
use-case -- external sources.  I would like to see this able to be used in 
metadata sets as well.

Andy