Re: Silva 2.2b1dev-r35291: KupuPopupWindow Field

On 22. Jul 2009, at 22. Jul 2009|14:30 Uhr, Andy Altepeter wrote:

> 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).

Ok, thanks for the information. personally, i have never used citation  
before.

>
>>>>> 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.

i would prefer to use kupu and not tinymce. when using KupuPopupWindow  
i automatically get valid silva-xml data and in the backend i can  
create silva documents if needed.

>>
>>>>> 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.

interesting idea. will there also be a KupuEmbededWindow?

regards,
marc

_______________________________________________
silva-dev mailing list
silva-dev-IAPFreCvJWM6s/[email protected]
https://lists.infrae.com/mailman/listinfo/silva-dev