Proposal: Extract the javascript framework specifics into their own modules

1 view
Skip to first unread message

Dirk Louwers

unread,
Mar 29, 2010, 4:56:47 PM3/29/10
to Lift
Hi,

I am writing this regarding a recent discussion and ticket #446:
https://www.assembla.com/spaces/liftweb/tickets/446-extract-the-javascript-framework-specifics-into-their-own-modules

The proposal is to make Lift-Webkit lighter by extracting specific
javascript frameworks and their related scala code into their own
modules. The idea is to maintain the current package names.

Please let me know what your thoughts are on this.

In the phase thereafter I am planning to see what JqJsCmnds and
JqSHtml have to offer and try to abstract (some of) that functionality
so that javascript frameworks can support a second capability tier. I
can fill in the jQuery implementation of that from what is already
there and provide the one for (the newly added) Ext-Core. Ideally the
Lift example website should then be updated to run with different
javascript frameworks backing it.

I would like to hear what your thoughts are on these proposals.

Best,

Dirk Louwers

Timothy Perrett

unread,
Mar 29, 2010, 5:19:13 PM3/29/10
to lif...@googlegroups.com
Dirk, this was totally the right thing to do bringing this on-list. Thank you.

Your proposal is compelling, and as per review-board, I agree we should take this step. Its a really positive one.

The only thing we need to figure is how we manage the defaults - i.e. how do we ensure JQuery is the default javascript dependency at a project level? I guess we could manage this through archetypes for now.

Cheers, Tim

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>

Dirk Louwers

unread,
Mar 29, 2010, 5:51:38 PM3/29/10
to Lift
Personally I am not much of a convention over configuration proponent,
but in keeping with the framework I guess that going by jquery's
popularity it should be the default indeed. (See Google Trends:
http://www.google.com/trends?q=jquery%2C+ext%2C+yui&ctab=0&geo=all&date=all&sort=0).
Making the default archetype the one including jQuery seems sensible.
I assume people have come to expect it to be included in a vanilla
Lift archetype.

Regarding my proposal on the next phase: I'd like to identify what js
"widgets" are most commonly used and try to abstract the
implementation of these so that people can use the most common ones
with whatever javascript framework they are using supporting such
capabilities. From what I've identified so far in the example
application a date picker and modal dialog are likely candidates.

Best,

Dirk

On 29 mrt, 23:19, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Dirk, this was totally the right thing to do bringing this on-list. Thank you.
>
> Your proposal is compelling, and as per review-board, I agree we should take this step. Its a really positive one.
>
> The only thing we need to figure is how we manage the defaults - i.e. how do we ensure JQuery is the default javascript dependency at a project level? I guess we could manage this through archetypes for now.
>
> Cheers, Tim
>
> On 29 Mar 2010, at 21:56, Dirk Louwers wrote:
>
> > Hi,
>
> > I am writing this regarding a recent discussion and ticket #446:

> >https://www.assembla.com/spaces/liftweb/tickets/446-extract-the-javas...

Dirk Louwers

unread,
Mar 29, 2010, 6:08:51 PM3/29/10
to Lift
Oh and maybe I am rocking the boat here but I'd really appreciate a
nice rich client side developer/debug toolbar. One that can display
the likes of query profiling, profiling of different stages of the
request and app lifecycle, and possible displaying of other logs. I
know this is probably going to be way more complex than a datepicker
but it seems quite usefull if you are developing a RIA. A nice tabular/
tree stacktrace in a dialog box beats having to catch a stacktrace
from the console server side.

On 29 mrt, 23:51, Dirk Louwers <dirk.louw...@stormlantern.nl> wrote:
> Personally I am not much of a convention over configuration proponent,
> but in keeping with the framework I guess that going by jquery's

> popularity it should be the default indeed. (See Google Trends:http://www.google.com/trends?q=jquery%2C+ext%2C+yui&ctab=0&geo=all&da...).

Dirk Louwers

unread,
Mar 29, 2010, 6:13:34 PM3/29/10
to Lift
Oh and maybe I am rocking the boat here but I'd really appreciate a
nice rich client side developer/debug toolbar. One that can display
the likes of query profiling, profiling of different stages of the
request and app lifecycle, and possible displaying of other logs. I
know this is probably going to be way more complex than a datepicker
but it seems quite usefull if you are developing a RIA. A nice tabular/
tree stacktrace in a dialog box beats having to catch a stacktrace
from the console server side.

On 29 mrt, 23:51, Dirk Louwers <dirk.louw...@stormlantern.nl> wrote:

> Personally I am not much of a convention over configuration proponent,
> but in keeping with the framework I guess that going by jquery's

> popularity it should be the default indeed. (See Google Trends:http://www.google.com/trends?q=jquery%2C+ext%2C+yui&ctab=0&geo=all&da...).

Timothy Perrett

unread,
Mar 29, 2010, 6:24:48 PM3/29/10
to lif...@googlegroups.com
You could probably provide this as an arbitrary plugin following the Thing.init idiom that widgets use to configure handlers and so on. There is a desire to keep everything as light as possible (many plugins over monolithic core) so id certainly see this as a plugin candidate for sure - it would be useful for most webapps.

Otherwise, I like the suggestion for common things like modal dialog. Rock something out on a branch and lets check it out :-)

Awesome stuff Dirk - keep it coming.

Cheers, Tim

Marius

unread,
Mar 30, 2010, 2:14:52 AM3/30/10
to Lift
+1

On Mar 29, 11:56 pm, Dirk Louwers <dirk.louw...@stormlantern.nl>
wrote:
> Hi,
>
> I am writing this regarding a recent discussion and ticket #446:https://www.assembla.com/spaces/liftweb/tickets/446-extract-the-javas...

Dirk Louwers

unread,
Apr 4, 2010, 9:03:44 AM4/4/10
to Lift
Ok, I am now going to proceed with making my first incisions!

David Pollak

unread,
Apr 4, 2010, 9:56:55 AM4/4/10
to lif...@googlegroups.com
On Sun, Apr 4, 2010 at 6:03 AM, Dirk Louwers <dirk.l...@stormlantern.nl> wrote:
Ok, I am now going to proceed with making my first incisions!


Dirk,

Lift is going to switch from defaulting to Scala 2.7.x to defaulting to Scala 2.8 during the next month. There will continue to be an actively maintained 2.7.x branch, but it will no longer be the default.

Scala 2.8 offers package objects which are convenient places to put aliases so that we can do code-break-free aliasing of new locations for packages and stuff.

You might want to use the 2.8 branch for your work so that you can simultaneously break the JavaScript stuff out of WebKit and use the package object feature to insure code migration.

Thanks,

David
 
--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Dirk Louwers

unread,
Apr 4, 2010, 10:24:35 AM4/4/10
to Lift
Hi David,

Thanks for pointing that out. Luckily haven't done too much work from
the master branch yet so can easily switch over.

Is there a particular place/resource that I can refer to to get a feel
for the package object feature?

Best,

Dirk

On 4 apr, 15:56, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> On Sun, Apr 4, 2010 at 6:03 AM, Dirk Louwers

> <dirk.louw...@stormlantern.nl>wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>


> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

David Pollak

unread,
Apr 4, 2010, 10:42:01 AM4/4/10
to lif...@googlegroups.com
On Sun, Apr 4, 2010 at 7:24 AM, Dirk Louwers <dirk.l...@stormlantern.nl> wrote:
Hi David,

Thanks for pointing that out. Luckily haven't done too much work from
the master branch yet so can easily switch over.

Is there a particular place/resource that I can refer to to get a feel
for the package object feature?

I think the best place is the Scala library source itself... the Scala folks have made heavy use of Package Objects to move libraries hierarchies around.... sorry that I don't have a more specific pointer than that. :-(
 
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890

Dirk Louwers

unread,
Apr 4, 2010, 1:06:38 PM4/4/10
to Lift
Am having diffiulty identifying the correct branch, is that the
280_port branch?

On 4 apr, 15:56, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> On Sun, Apr 4, 2010 at 6:03 AM, Dirk Louwers

> <dirk.louw...@stormlantern.nl>wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>


> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

Dirk Louwers

unread,
Apr 4, 2010, 1:12:06 PM4/4/10
to Lift
Am having diffiulty identifying the correct branch, is that the
280_port branch?

On 4 apr, 15:56, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> On Sun, Apr 4, 2010 at 6:03 AM, Dirk Louwers

> <dirk.louw...@stormlantern.nl>wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>


> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

Dirk Louwers

unread,
Apr 4, 2010, 1:13:34 PM4/4/10
to Lift
Am having diffiulty identifying the correct branch, is that the
280_port branch?

On 4 apr, 15:56, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> On Sun, Apr 4, 2010 at 6:03 AM, Dirk Louwers

> <dirk.louw...@stormlantern.nl>wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>


> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

Timothy Perrett

unread,
Apr 4, 2010, 1:13:43 PM4/4/10
to lif...@googlegroups.com
Its the 280_port_refresh branch

Cheers, Tim

> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

Dirk Louwers

unread,
Apr 4, 2010, 1:14:45 PM4/4/10
to Lift
Cheers, sorry for the spam. Was impatiently refreshing forgetting that
I would repost my last message.

Indrajit Raychaudhuri

unread,
Apr 5, 2010, 6:13:19 AM4/5/10
to Lift
Dirk,

Sorry for pitching in late :)
I am yet to digest the discussion thread, but would certainly look
forward to this.

Couple of points:

- I had posted a kind of 'wishlist' sometime back along the lines in
the context of Javascript DSL[1]. See if that is useful.
- Regarding package object, you might have a look at Dean's book [2]
and scalaodules [3].

Cheers, Indrajit

[1] http://groups.google.com/group/liftweb/msg/cc90c4015d2fbecb
[2] http://programming-scala.labs.oreilly.com/ch07.html#PackageObjects
[3]
http://github.com/weiglewilczek/scalamodules/blob/master/framework/core/scalamodules-core/src/main/scala/org/eclipse/scalamodules/core/package.scala

Reply all
Reply to author
Forward
0 new messages