[opencms-dev] iframe-base custom widgets ....

[Ruben Malchow]

hi michael,

yes, this might be a reasonable approach for some things. however, i 
still find that it has some problems. for one, you still have a somewhat 
tight coupling between the class and the html/js/css. also, in this way, 
it might become a bit difficult when get into ajax things, especially 
the escaping of strings - i found this to be a bit confusing at times (i 
mean things like:

	function myJsFunction (a) {
		somevalue = '$[SOME_TOKEN_TO_BE_REPLACED]';
		timer = setTimeout('myJsFunction(\"'+somevalue+'\",500);
	}

this a made-up example, of  course, but it does happen like this. and 
with the different places involved, it might be difficult to find out at 
which place you will need how many layers of escaping (do you remember 
TCL? hehe).

so actually, i would still believe that having generic widget class that 
can load various different JSPs into an iframe depending on the 
configuration would make a really clean cut there, and a defined 
'interface' between the stuff in the iframe and the editor is rather 
easy ... right now, i have implemented an image choser that works really 
nicely, displaying thumbnails and so on. i think i will try to extract 
the code for that from the rest of my project and try to package it with 
an example ...

.rm


Michael Moossen wrote:
> Hi, Ruben!
> 
> well, what i have done before for very large and nice widgets is to have 
> the widget class loading (and caching) html fragments from VFS files. 
> for this i normally create a module with following structure:
> system
>    modules
>      my.nice.widget
>        elements
>          headers.html (css + js includes)
>          html-templates.xml (generic XML content with templates)
>          messages.xml (generic XML content with localization messages, i 
> prefer this instead of resource bundles since no restart needed)
>        lib
>          my.nice.widget.jar (the widget code)
>        resources (all static files)
>          css
>          images
>          js
>        schemas (xsd's for the templates and messages)
> 
> for html generation i use a macro resolver for setting the id and value 
> in the correct place, as well as localized strings coming from the 
> messages.xml and options coming from the widget configuration.
> 
> so the most important methods of the widget class would look like this:
> 
> public String getDialogIncludes(CmsObject cms, I_CmsWidgetDialog 
> widgetDialog) {
> 
>     return the content of headers.html
> }
> 
> public String getDialogWidget(CmsObject cms, I_CmsWidgetDialog 
> widgetDialog, I_CmsWidgetParameter param) {
> 
>     create a macro resolver
>     put the id and the value of the widget in the macro resolver
>     put all messages for the right locale in messages.xml in the macro 
> resolver
>     put all templates in html-templates.xml in the macro resolver (i use 
> this to selected the displayed controls depending on the options)
>     read the main template element from html-templates.xml, resolve the 
> macros and return the result
> }
> 
> HTH
> --
> Michael Moossen
> 
> Alkacon Software GmbH  - The OpenCms Experts
> http://www.alkacon.com - http://www.opencms.org
> 
> 
> Ruben Malchow wrote:
>> hi,
>>
>> with the widgets available, i have always had a somewhat tense 
>> relationship. it is very hard to implement something really nice with 
>> that. and html code in classes is the only big thing i hate about 
>> opencms. for example, somewhat more complicated chosers are a pain in 
>> the butt to implement.
>>
>> now ... i am attaching a little snippet that would give you an 
>> iframe-based choser. of course, the jsp (or even the HTML page) will not 
>> have all the context that the getDialogWidget method has, but for many 
>> things, it should be enough.
>>
>> using this, it is possible to implement custom widgets using only jsp 
>> code. a proper, let's say "IFrameWidget" class could have enough 
>> configuration options to accomodate plenty of the everyday problems.
>>
>> actually, this mightbe extended to provide an "edit" and a "display" 
>> mode, this should be easy to implement.
>>
>> any thoughts on this?
>>
>>
>> .rm
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
> 
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>