On Mar 6, 9:14 pm, Peter Robinett <[email protected]> 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 <[email protected]> wrote:
>
>
>
> > Marius <[email protected]> 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 [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.
