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." <[email protected]> wrote: > On Jul 12, 6:06 pm, "marius d." <[email protected]> wrote: > > > On Jul 12, 6:04 pm, Francois Bertrand <[email protected]> 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." <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
