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 > > 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.
