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 <[email protected]> wrote:
> 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.
