Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: [...] Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work I think my use case is slightly different, but can still be handled with the above. Basically, I don't want the dependencies to show up in my markup, but be handled by higher level components (or snippets) In my markup, I'll have a high level snippet: lift:Chart.render stuff /lift:Chart.render The chart snippet will now, depending on a lot of factors, emit a number of dependencies (eg jquery, jqplot a pie chart render). But I think this should still work given the above. [...] I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects duplicates. I agree, lets see if this becomes a problem I think this would cover snippets and comet actors and it should also work for LiftView-s Thoughts ? Sounds good. But it seems to leave the dependency management to the user (e.g. in the above scenario, I would have to declare all 3 dependencies, not just the pie chart render, that will then include jqplot that will then include jquery) ?? This is not necessarily a bad thing. /Jeppe [...] -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Marius, I love the simplicity of your proposal but I think that's also its problem. Let's say I have something with several dependencies: lift:MySnipet.work lift:dependencies script src=dep1.js/ script src=dep2.js/ script src=myLib.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work As you can see, the user may as well be writing raw XHTML for a head tag: they're required to know all the dependencies and put them in the correct order. Of course library authors can make this easier by writing snippets and such that provide the dependencies: def flotSelectableJS = lift:dependencies script src=/classpath/jquery.js/ script src=/classpath/jquery.flot.js/ script src=/classpath/jquery.flot.selectable.js/ /lift:dependencies However, there is no representation of the Javascript files and their individual dependencies independent on the XML tags and the order in which they are placed. This is why I like using a Scala class better: a developer can look at any instance of a Javascript file class and see its dependencies without having to do any (easy) XML querying, only converting the instance to XML when necessary. I guess one reason I am pushing this approach is that I'm thinking in terms of lift-flot, where the user does all their manipulation of the charts in straight Scala, not Javascript or XHTML. This is also corresponds to how various Javascript and jQuery operations are represented in net.liftweb.http.js, and I'd like to complement them and continue in that vein. Oh, and I definitely want to be able to have conditional snippets like you mention, that's a great feature. What do you think? Peter On Mar 6, 11:33 am, Marius marius.dan...@gmail.com wrote: On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work lift:comet ... lift:dependencies script src=bla.js/ /// you got the ides /lift:dependencies ... /lift:comet In this sense we are describing dependencies (could be both js and css) per snippet / per comet. the dependencies snippet could be either eagerly evaluated or not - shouldn't really matter. What it does it just put the script and link tags in a head element that lift will automatically merge. This could also be useful for conditional snippets . Say we have snippet A and snippet B on the same page each having different dependencies. But snippet A is invoked only when the user is logged on and snippet B only when user is logged off. Thus we won't have to modify scala API at all. Cause it seems that Lift already provides the goodies for us. Of course this can work even today if we replace lift:dependencies with head tag but people would probably find this nomenclature odd. I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects duplicates. I think this would cover snippets and comet actors and it should also work for LiftView-s Thoughts ? So, what if we have something like req.registerDependency(myJsScript)? The Request would store the dependencies that the LiftResponse would then take, resolve, and merge into the XHTML it's outputting. However, CometActors exist outside of normal requests. How do we get around this? CometActors are created initially in a Request, so
[Lift] Re: Javascript Dependencies
On Mar 8, 11:02 am, Peter Robinett pe...@bubblefoundry.com wrote: Marius, I love the simplicity of your proposal but I think that's also its problem. Let's say I have something with several dependencies: lift:MySnipet.work lift:dependencies script src=dep1.js/ script src=dep2.js/ script src=myLib.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work As you can see, the user may as well be writing raw XHTML for a head tag: they're required to know all the dependencies and put them in the correct order. Of course library authors can make this easier by writing snippets and such that provide the dependencies: def flotSelectableJS = lift:dependencies script src=/classpath/jquery.js/ script src=/classpath/jquery.flot.js/ script src=/classpath/jquery.flot.selectable.js/ /lift:dependencies However, there is no representation of the Javascript files and their individual dependencies independent on the XML tags and the order in which they are placed. This is why I like using a Scala class better: a developer can look at any instance of a Javascript file class and see its dependencies without having to do any (easy) XML querying, only converting the instance to XML when necessary. I guess one reason I am pushing this approach is that I'm thinking in terms of lift-flot, where the user does all their manipulation of the charts in straight Scala, not Javascript or XHTML. This is also corresponds to how various Javascript and jQuery operations are represented in net.liftweb.http.js, and I'd like to complement them and continue in that vein. Please feel free to implement your proposal and we'll discuss either here or on review board. Oh, and I definitely want to be able to have conditional snippets like you mention, that's a great feature. Conditional snippets are supported today. For instance TestCond.loggedn or TestCont.loggedOut snippets. Any application can choose to render or not a snippet especially when talking about nested snippets. What do you think? Peter On Mar 6, 11:33 am, Marius marius.dan...@gmail.com wrote: On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work lift:comet ... lift:dependencies script src=bla.js/ /// you got the ides /lift:dependencies ... /lift:comet In this sense we are describing dependencies (could be both js and css) per snippet / per comet. the dependencies snippet could be either eagerly evaluated or not - shouldn't really matter. What it does it just put the script and link tags in a head element that lift will automatically merge. This could also be useful for conditional snippets . Say we have snippet A and snippet B on the same page each having different dependencies. But snippet A is invoked only when the user is logged on and snippet B only when user is logged off. Thus we won't have to modify scala API at all. Cause it seems that Lift already provides the goodies for us. Of course this can work even today if we replace lift:dependencies with head tag but people would probably find this nomenclature odd. I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects
[Lift] Re: Javascript Dependencies
Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies: http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. So, what if we have something like req.registerDependency(myJsScript)? The Request would store the dependencies that the LiftResponse would then take, resolve, and merge into the XHTML it's outputting. However, CometActors exist outside of normal requests. How do we get around this? CometActors are created initially in a Request, so we should be able to connect then but I don't know that part of Lift well enough to say how. Jeppe, Marius, what do you think? Am I on the right track? Do my suggestions address both of your concerns? Peter On Mar 1, 7:17 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies Yes I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. I think the two can co-exist, although I haven't thought it through wrt comet actors etc. That was what I was hinting at in the previous mail. At the of the day (or before sending a response at least :-) a page needs to have a well-defined list of script files to include. So it makes sense to start with your paradigm and my paradigm should be able to be layered on top if one wishes... However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? I'll let Peter take the lead and help where ever I can :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work lift:comet ... lift:dependencies script src=bla.js/ /// you got the ides /lift:dependencies ... /lift:comet In this sense we are describing dependencies (could be both js and css) per snippet / per comet. the dependencies snippet could be either eagerly evaluated or not - shouldn't really matter. What it does it just put the script and link tags in a head element that lift will automatically merge. This could also be useful for conditional snippets . Say we have snippet A and snippet B on the same page each having different dependencies. But snippet A is invoked only when the user is logged on and snippet B only when user is logged off. Thus we won't have to modify scala API at all. Cause it seems that Lift already provides the goodies for us. Of course this can work even today if we replace lift:dependencies with head tag but people would probably find this nomenclature odd. I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects duplicates. I think this would cover snippets and comet actors and it should also work for LiftView-s Thoughts ? So, what if we have something like req.registerDependency(myJsScript)? The Request would store the dependencies that the LiftResponse would then take, resolve, and merge into the XHTML it's outputting. However, CometActors exist outside of normal requests. How do we get around this? CometActors are created initially in a Request, so we should be able to connect then but I don't know that part of Lift well enough to say how. Jeppe, Marius, what do you think? Am I on the right track? Do my suggestions address both of your concerns? Peter On Mar 1, 7:17 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies Yes I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. I think the two can co-exist, although I haven't thought it through wrt comet actors etc. That was what I was hinting at in the previous mail. At the of the day (or before sending a response at least :-) a page needs to have a well-defined list of script files to include. So it makes sense to start with your paradigm and my paradigm should be able to be layered on top if one wishes... However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? I'll let Peter take the lead and help where ever I can :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Yes I believe this needs a bit more thinking. I didn;t spend too much
time into this but perhaps add a LiftRules function to describe the
dependency tree per page:
i.e.
var jsDependencies : (Req) = JsDependencyTree
where
case class JsDependencyTree (url: String, dependencies:
JsDependencyTree *) // not sure if we'd need more info
The head merge (and potentially tail merge as well) mechanism in Lift
would obtain the JsDependencyTree from LiftRules passing the Req
(hence you can have a different dependency tree per page, or per
application depending how you do pattern matching). Thus head merge
would arrange the scripts according to the dependency tree. If a
script is not in the dependency tree, it will just be appended to the
scripts list. Adjacent features that I see:
1. Detect if a dependency is missing
2. Construct a suite of dependency trees for most used JQuery plugins
that people can easily re-use.
Br's,
Marius
On Mar 1, 1:54 am, Peter Robinett pe...@bubblefoundry.com wrote:
Issue 281 is not going to make it into M3. The specific issue that
needs to be solved first is how to manage dependencies across multiple
snippets on one page. See the Assembla page for more
information:http://www.assembla.com/spaces/liftweb/tickets/281
Peter
On Feb 26, 5:14 pm, Peter Robinett pe...@bubblefoundry.com wrote:
Mads, thanks for bringing ticket 281 to my attention, I'll address it
in my patch.
Jeppe, that's how I plan on using it with Flot: having Flot.init
register the plugins and in the charts call toHTML as needed.
Should have everything up on my pr1001_issue_322 branch by tomorrow.
Peter
On Feb 25, 1:14 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Peter Robinett pe...@bubblefoundry.com writes:
Hi all,
[...]
// Usage in boot.scala
val myJsScript = new JsScript(flot :: jquery.flot.selectable.js ::
Nil)
ResourceServer.allow(myJsScript.allowResource)
// Usage in a normal snippet
def mySnippet = {
head
{ myJsScript.toHTML }
/head
div
The rest of the snippet...
/div
}
// Usage in a CometActor
class myActor extends CometActor with JsScriptDependency {
override def scripts = List(new JsScript(flot ::
jquery.flot.selectable.js :: Nil));
}
What do you think? It's a really quite basic but I think such an
approach could work well for things like as lift-flot.
It might be a start :-) I'm a little unsure if it supports the use case
I would like to see:
I'm using jqPlot (a flot-like lib) and would like to, in boot, just
initialize the widget:
jqPlot.init
jqPlot comes with numerous plugins and this should be handled by the
widget. Whether a plugin is loaded on a page depends on some higher
level structure. Ie. if I wish to draw a pie chart, the pie chart plugin
should be loaded.
Looking back at this, it seems like this could work with the above
In init: register all plugins
In the specific charts, call toHtml on the plugins needed
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Javascript Dependencies
On Mar 1, 1:50 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: Yes I believe this needs a bit more thinking. I didn;t spend too much time into this but perhaps add a LiftRules function to describe the dependency tree per page: i.e. var jsDependencies : (Req) = JsDependencyTree where case class JsDependencyTree (url: String, dependencies: JsDependencyTree *) // not sure if we'd need more info The head merge (and potentially tail merge as well) mechanism in Lift would obtain the JsDependencyTree from LiftRules passing the Req (hence you can have a different dependency tree per page, or per application depending how you do pattern matching). Thus head merge would arrange the scripts according to the dependency tree. If a script is not in the dependency tree, it will just be appended to the scripts list. I can't help to think this is a bit too low level. I would hate to have to go in and modify LiftRules everytime I add/change something on a page. Or maybe I don't understand it correctly? The way I see it, we can have some named values that corresponds to files that need to be included (not sure about actual syntax), ie In snippet A: I need flot In snippet B: I need flot-piechart-plugin It seems fairly straight forward to compute a tree of dependencies (basically the JsDependencyTree) having the correct order depending on the above declarations: Process snippets in order and avoid duplicates: A needs Flot which needs Jquery - [jquery, flot] B needs flot-piechart-plugin which needs flot which needs jquery - [jquery, flot] ++ [jquery, flot, flot-piechart-plugin] = [jquery, flot, flot-piechart-plugin] I'm not sure that doing this per snippet is the right approach. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. There will have to be some validations (circular dependencies etc), but this should be fixable Adjacent features that I see: 1. Detect if a dependency is missing 2. Construct a suite of dependency trees for most used JQuery plugins that people can easily re-use. That would be cool /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: [...] I'm not sure that doing this per snippet is the right approach. Maybe we differ in our thinking then :-) I'm thinking more in a component oriented approach where I would like to put a widget on a page. I'll just add the correct snippet tags to my page and don't want to worry about which js dependencies I need to include before the snippet works. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. Yeah, maybe some flexibility is needed and as usual it seems like a good idea to have the low level foundations in place first and build the higher level abstractions on top. If we have the function in LiftRules it should be possible to what I want by creating a smarter Req = Tree function. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? Br's, Marius On Mar 1, 2:45 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: [...] I'm not sure that doing this per snippet is the right approach. Maybe we differ in our thinking then :-) I'm thinking more in a component oriented approach where I would like to put a widget on a page. I'll just add the correct snippet tags to my page and don't want to worry about which js dependencies I need to include before the snippet works. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. Yeah, maybe some flexibility is needed and as usual it seems like a good idea to have the low level foundations in place first and build the higher level abstractions on top. If we have the function in LiftRules it should be possible to what I want by creating a smarter Req = Tree function. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies Yes I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. I think the two can co-exist, although I haven't thought it through wrt comet actors etc. That was what I was hinting at in the previous mail. At the of the day (or before sending a response at least :-) a page needs to have a well-defined list of script files to include. So it makes sense to start with your paradigm and my paradigm should be able to be layered on top if one wishes... However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? I'll let Peter take the lead and help where ever I can :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Issue 281 is not going to make it into M3. The specific issue that
needs to be solved first is how to manage dependencies across multiple
snippets on one page. See the Assembla page for more information:
http://www.assembla.com/spaces/liftweb/tickets/281
Peter
On Feb 26, 5:14 pm, Peter Robinett pe...@bubblefoundry.com wrote:
Mads, thanks for bringing ticket 281 to my attention, I'll address it
in my patch.
Jeppe, that's how I plan on using it with Flot: having Flot.init
register the plugins and in the charts call toHTML as needed.
Should have everything up on my pr1001_issue_322 branch by tomorrow.
Peter
On Feb 25, 1:14 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Peter Robinett pe...@bubblefoundry.com writes:
Hi all,
[...]
// Usage in boot.scala
val myJsScript = new JsScript(flot :: jquery.flot.selectable.js ::
Nil)
ResourceServer.allow(myJsScript.allowResource)
// Usage in a normal snippet
def mySnippet = {
head
{ myJsScript.toHTML }
/head
div
The rest of the snippet...
/div
}
// Usage in a CometActor
class myActor extends CometActor with JsScriptDependency {
override def scripts = List(new JsScript(flot ::
jquery.flot.selectable.js :: Nil));
}
What do you think? It's a really quite basic but I think such an
approach could work well for things like as lift-flot.
It might be a start :-) I'm a little unsure if it supports the use case
I would like to see:
I'm using jqPlot (a flot-like lib) and would like to, in boot, just
initialize the widget:
jqPlot.init
jqPlot comes with numerous plugins and this should be handled by the
widget. Whether a plugin is loaded on a page depends on some higher
level structure. Ie. if I wish to draw a pie chart, the pie chart plugin
should be loaded.
Looking back at this, it seems like this could work with the above
In init: register all plugins
In the specific charts, call toHtml on the plugins needed
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Javascript Dependencies
Mads, thanks for bringing ticket 281 to my attention, I'll address it
in my patch.
Jeppe, that's how I plan on using it with Flot: having Flot.init
register the plugins and in the charts call toHTML as needed.
Should have everything up on my pr1001_issue_322 branch by tomorrow.
Peter
On Feb 25, 1:14 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Peter Robinett pe...@bubblefoundry.com writes:
Hi all,
[...]
// Usage in boot.scala
val myJsScript = new JsScript(flot :: jquery.flot.selectable.js ::
Nil)
ResourceServer.allow(myJsScript.allowResource)
// Usage in a normal snippet
def mySnippet = {
head
{ myJsScript.toHTML }
/head
div
The rest of the snippet...
/div
}
// Usage in a CometActor
class myActor extends CometActor with JsScriptDependency {
override def scripts = List(new JsScript(flot ::
jquery.flot.selectable.js :: Nil));
}
What do you think? It's a really quite basic but I think such an
approach could work well for things like as lift-flot.
It might be a start :-) I'm a little unsure if it supports the use case
I would like to see:
I'm using jqPlot (a flot-like lib) and would like to, in boot, just
initialize the widget:
jqPlot.init
jqPlot comes with numerous plugins and this should be handled by the
widget. Whether a plugin is loaded on a page depends on some higher
level structure. Ie. if I wish to draw a pie chart, the pie chart plugin
should be loaded.
Looking back at this, it seems like this could work with the above
In init: register all plugins
In the specific charts, call toHtml on the plugins needed
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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.
