[Lift] Re: Standardizing widget APIs
Thanks guys - all very interesting. Had an offline talk with marius and it seems that there was an effort to standardize the api from the outset which subsequently didnt work out... Im happy to leave this for now as im not sure there is any tangible benefit. Cheers, Tim On Jul 12, 4:23 pm, marius d. marius.dan...@gmail.com wrote: On Jul 12, 6:06 pm, marius d. marius.dan...@gmail.com wrote: On Jul 12, 6:04 pm, Francois Bertrand fber...@gmail.com wrote: If more and more widgets are added, there is a potential version problem with referenced CSS/js resources they may need to share. For example, the Flot widget needs the google canvas for IE (http:// excanvas.sourceforge.net/). Actually this javascript is inside the Flot widget code and it shouldn't be there. BTW Lift-widgets has a common folder under /resources/to/serve where common scripts should be placed. If it turns out that a script needs to be used by multiple widgets it should probably be placed be placed there. Furthermore a widget doesn't have to be part of lift-widgets project. Anyone can build a widget and package it in a single jar file including resources like (js, css, images etc) and distribute it. Another problem is, if the same widget is used twice in the same page, how do I avoid include the CSS/js resources twice? Lift takes care of that when it merges heads. Is is a problem if the widget needs a one time per page initialization. In both case, a API to manage shared resource would be useful. What API are you talking about? ... the resource referencing (js, css, images etc.) are referenced by path only and common resources should be placed in common folder. Do we need more then that? Furthermore if someone develops a bunch of widgets that conceptually pertain to the same family constructing a proper structure to place family common scripts is trivial. Maybe, Lift has an elegant solution I'm not aware of and only a little documentation will suffice. Francois On Jul 12, 2:58 am, marius d. marius.dan...@gmail.com wrote: Well widgets don't have a whole lot of commonalities besides the init () method. Regarding destroy() that would probably be helpful for widgets that are communicating remotely with other services. The rest of the widget functions are mostly very specific helper functions that renders markup, JS script tags etc, and work with very specific data models. Br's Marius On Jul 12, 3:03 am, Timothy Perrett timo...@getintheloop.eu wrote: I'm not sure, depends I guess. Just a simple onLoad/onUnload callback could be enough... (The unload is to make sure not to leak mem if you're just reloading the webapp without restarting the server) That was my thinking - right now the pattern appears to be def init for booting the widget, so perhaps, init and destroy methods would be good appropriate. Like I said, just something to make this stuff a known, typeable quantity would be good. Java Specialist Scala Loudmouth Lift Committer What happened to your rouge architect signature?! Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Standardizing widget APIs
Well widgets don't have a whole lot of commonalities besides the init () method. Regarding destroy() that would probably be helpful for widgets that are communicating remotely with other services. The rest of the widget functions are mostly very specific helper functions that renders markup, JS script tags etc, and work with very specific data models. Br's Marius On Jul 12, 3:03 am, Timothy Perrett timo...@getintheloop.eu wrote: I'm not sure, depends I guess. Just a simple onLoad/onUnload callback could be enough... (The unload is to make sure not to leak mem if you're just reloading the webapp without restarting the server) That was my thinking - right now the pattern appears to be def init for booting the widget, so perhaps, init and destroy methods would be good appropriate. Like I said, just something to make this stuff a known, typeable quantity would be good. Java Specialist Scala Loudmouth Lift Committer What happened to your rouge architect signature?! Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Standardizing widget APIs
Any technical feedback Viktor? Suggestions for possible ways to enforce a structure / life-cycle? Cheers, Tim I like it --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Standardizing widget APIs
On Sat, Jul 11, 2009 at 10:15 PM, Timothy Perrett timo...@getintheloop.euwrote: Any technical feedback Viktor? Suggestions for possible ways to enforce a structure / life-cycle? I'm not sure, depends I guess. Just a simple onLoad/onUnload callback could be enough... (The unload is to make sure not to leak mem if you're just reloading the webapp without restarting the server) Cheers, Tim I like it -- Viktor Klang Java Specialist Scala Loudmouth Lift Committer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Standardizing widget APIs
I'm not sure, depends I guess. Just a simple onLoad/onUnload callback could be enough... (The unload is to make sure not to leak mem if you're just reloading the webapp without restarting the server) That was my thinking - right now the pattern appears to be def init for booting the widget, so perhaps, init and destroy methods would be good appropriate. Like I said, just something to make this stuff a known, typeable quantity would be good. Java Specialist Scala Loudmouth Lift Committer What happened to your rouge architect signature?! Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
