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.
