Hi Pim,
Can there be different dragdrop instances?
-> yes I made that yesterday. It works but I didn’t commit it, cause now we have a performance problem with too many ADD_DTHML calls in calendar (PHP is fast, but local JavaScript takes too long [about 3seconds on my laptop]). I must analyze the problem furhter and maybe change wz_dragdrop.js a bit.
How do will deal with the custom functions like my_DropFunc()
-> you can assign custom DropFunc() and DragFunc() to EVERY defined object, like for the draggables or droppables. The custom DHTML object will support this too. The main problem will be, that this cannot be code directly, it must be a file location somewhere, like dropaction=“application.file.function”. Could you live with that, e.g. I think your js-code must resist then in phpgwapi/js/idotstemplate.js in function moveSidebar() ??
auto-disabling browsers
$dragdrop->validateBrowser() gives true or false. If false, the browser is not supported for eGW DHTML, e.g. IE. I think we can avoid many browser-based problems with this compatibility check. On the other hand, you have to code alternative behaviour, in your case a fixed width and no resize icon. I think this is better than enabling all DHTML by default and wait for the many, many “my browser crashes…”-entries in the forum.
Many Greetings
Christian
Op woensdag 03 januari 2007 20:48, schreef jaytraxx:
> Hey guys,
>
> now here's my plan of action to make resizeable sidebar and other dragdrop
> (e.g. calendar atm) working in symbiosis :o)
>
> - make class.dragdrop.inc.php aware of multiple instances and handle all
> the inclusion of scripts an js output in general
Can there be different dragdrop instances?
- add a function in class.dragdrop.inc.php -> addCustom - this class allows
to generate custom DHTML objects for any needs
so, this must work afterwards …
How do will deal with the custom functions like my_DropFunc()
what’s not totally clear for me at the moment:
- class.dragdrop.inc.php auto-disables all DHTML action if browser is not
set as compatible:
–> so, every developer has eventually to care for an alternative if the
class auto-disables the DHTML functionality. I think a general
auto-disabling for all apps is better than disabling for every app itself,
cause it prevents better from incompatibility issues with incompatible
browsers… either a browser is full compatible with all DHTML objects or
not.
I don’t exactly know about this last thought.
Pim
Lingewoud B.V.
Achter 't Veer 12
4191 AD Geldermalsen
The Netherlands
Tel. +31 3455 82222
Fax. +31 3455 70090
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
[/quote]
