The Lift 3.0 discussion

[David Pollak]

Folks,

With the Lift 2.0 release looming, I think it's time to talk about the feature priorities for Lift 3.0.  I'll toss out my list (in no particular order):

• Using sbt as the default build system for Lift (this is my personal highest priority)
• Embracing Scala 2.8 including package objects, etc. to further enhance the Lift experience
• Easy-Peasy DSLs for creating quick sites (aka Lift's little brother).  Basically, make it easier to use Lift than any other framework for simple stuff... along the lines of the RestHelper stuff.  We can also use the type system within the confines of such a DSL to enforce "stateless", "serializable state" and "session affinity" apps.
• Enhanced control over session size, session monitoring, session migration, and session purging.
• Integration with Squeryl for query building
• Further refinement of mixin traits for field and form validation along with integration of client side validation

Please share your priorities... we'll get them into the Lift backlog and start prioritizing.

Thanks,

David

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

[Ross Mellgren]

Speaking of Squeryl, that integration is getting awful close to ready for wider use... once that happens the priorities in Record will probably shift towards CRUDify / proto user (or similar) for Record, so those would be on my list of priorities for 3.0

-Ross

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

[Timothy Perrett]

Yeah, moving Record along would be very much welcome.
David, your list sounds great. Looking forward to it.

Cheers, Tim

[harryh]

>    - Enhanced control over session size, session monitoring, session
>    migration, and session purging.

Related to this would be some clever tools/methods of limiting what
gets pulled into the session. As it is, it is pretty easy to shoot
yourself in the foot by storing (a lot) more state in the session than
you are really using which can lead to memory issues.

-harryh

[Jeppe Nejsum Madsen]

Sounds good! A few comments inline

David Pollak <feeder.of...@gmail.com> writes:

> Folks,
>
> With the Lift 2.0 release looming, I think it's time to talk about the
> feature priorities for Lift 3.0. I'll toss out my list (in no particular
> order):
>

> - Using sbt as the default build system for Lift (this is my personal
> highest priority)
> - Embracing Scala 2.8 including package objects, etc. to further enhance
> the Lift experience
> - Easy-Peasy DSLs for creating quick sites (aka Lift's little brother).

> Basically, make it easier to use Lift than any other framework for simple
> stuff... along the lines of the RestHelper stuff. We can also use the type
> system within the confines of such a DSL to enforce "stateless",
> "serializable state" and "session affinity" apps.

> - Enhanced control over session size, session monitoring, session
> migration, and session purging.
> - Integration with Squeryl for query building

I would like to see the Mapper/Record/Squeryl (and maybe JPA) stuff
streamlined.

> - Further refinement of mixin traits for field and form validation along

> with integration of client side validation

- Enhanced, composeable, extendable CRUDify that utilize the above
:-)
/Jeppe

[David Pollak]

I did CRUDify in a day to settle a bet with myself.  I'd love to get a list of what's missing from CRUDify so when we do the next version, it's more flexible and meets more needs out of the box.

 

      :-)
/Jeppe

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

[mshilts]

+1 for enhanced CRUDify.
+1 for stateless Lift.

-Matthew

[David Pollak]

On Mon, Jun 7, 2010 at 2:12 PM, mshilts <shi...@gmail.com> wrote:

+1 for enhanced CRUDify.
+1 for stateless Lift.

Ohhhhh.... now you tell me ;-)

(FYI -- Matthew was the very first victim... I mean user... of Lift)

 

-Matthew

> >      - Enhanced, composeable, extendable CRUDify that utilize the above
>
> I did CRUDify in a day to settle a bet with myself.  I'd love to get a list
> of what's missing from CRUDify so when we do the next version, it's more
> flexible and meets more needs out of the box.
>
> >       :-)
> > /Jeppe

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

[ngocdaothanh]

Sorry, but is there room for non-functional features, like
documentation?

On Jun 8, 6:42 am, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> On Mon, Jun 7, 2010 at 2:12 PM, mshilts <shi...@gmail.com> wrote:
> > +1 for enhanced CRUDify.
> > +1 for stateless Lift.
>
> Ohhhhh.... now you tell me ;-)
>
> (FYI -- Matthew was the very first victim... I mean user... of Lift)
>
>
>
>
>
>
>
> > -Matthew
>
> > > >      - Enhanced, composeable, extendable CRUDify that utilize the above
>
> > > I did CRUDify in a day to settle a bet with myself.  I'd love to get a
> > list
> > > of what's missing from CRUDify so when we do the next version, it's more
> > > flexible and meets more needs out of the box.
>
> > > >       :-)
> > > > /Jeppe
>
> > --
> > 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<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

[aw]

How about cleaning house? Like removing some things that you've
rethought and don't care about backwards compatibility?
- The Json that is pre-lift-json comes to mind.
- The legacy log4j stuff that pre-dates the recent logger/slf4j work.
I think the duplication is confusing to newbies.

What about making Lift compliant with 'Elements of Scala Style'?
http://www.codecommit.com/scala-style-guide.pdf
For example, on page 4: "Please note that the Lift convention of
appending _? to boolean accessors is non-standard and not used outside
of the Lift framework."

I'm very keen to see a Servlet 3.0 version of Comet.

Support for joda-time, scalaj-time or javax.time. After discovering a
serious bottleneck in java.util.Date, I am a convert to joda-time, and
java.time is practically an attempt to standardize it using a JSR.
Support in Mapper, Record, Json, REST, etc. would be nice.

Documentation... I find that there are gems that I am still
discovering. I certainly appreciate the blog entries that turn into
wiki entries. Reading wiki explanations and examples are faster than
trying to decipher the source code. (I'm looking forward to the
Summer of Code project for Collaborative Scaladoc.)

More sophisticated security model: allow/deny stacking, not just
additive; users, groups, roles, permissions, data restrictions. See
http://incubator.apache.org/shiro/ , http://static.springsource.org/spring-security/
, http://villane.wordpress.com/2010/01/21/a-simple-permission-based-security-library-in-scala/

Some handy dandy cache helpers (leverage ehcache's self populating
cache mechanism, for example). Being able to neatly cache security
privileges, database results, configuration settings, etc.

[Marius]

I started working on a pure stateless prototype following as close as
possible existent Lift's idioms. It would be mainly experimental
written mostly from scratch. Once I have something to share I will.

[Kevin Wright]

Is there any way to sort out the masses of boilerplate surrounding javascript usage?

The holy grail would have to be some sort of embedding, as with XML, or SQL (http://days2010.scala-lang.org/node/138/156)

SBT could make compiler plugins a more reasonable option here, with the javascript being converted to Lift objects in a very early compiler phase.

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

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[Mads Hartmann Jensen]

There were some chatter about integrating with Cappuccino on the list some time ago - I have a bachelor project coming up next spring and I have no idea what to work on yet ;) 

[Marius]

Interesting but I'm not really sure ... I've suggested a while back a
DSL for JavaScript that looked very much like JS code with just a few
boilerplate. Other people suggested it as well. But this did not have
much success as the design goal AFAIK was to to have a higher level
abstraction over JS constructs.

Br's,
Marius

On Jun 8, 11:39 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Is there any way to sort out the masses of boilerplate surrounding
> javascript usage?
>
> The holy grail would have to be some sort of embedding, as with XML, or SQL
> (http://days2010.scala-lang.org/node/138/156)
>
> SBT could make compiler plugins a more reasonable option here, with the
> javascript being converted to Lift objects in a very early compiler phase.
>

> On 8 June 2010 09:27, Marius <marius.dan...@gmail.com> wrote:
>
>
>
>
>
> > I started working on a pure stateless prototype following as close as
> > possible existent Lift's idioms. It would be mainly experimental
> > written mostly from scratch. Once I have something to share I will.
>
> > On Jun 8, 12:12 am, mshilts <shi...@gmail.com> wrote:
> > > +1 for enhanced CRUDify.
> > > +1 for stateless Lift.
>
> > > -Matthew
>
> > > > >      - Enhanced, composeable, extendable CRUDify that utilize the
> > above
>
> > > > I did CRUDify in a day to settle a bet with myself.  I'd love to get a
> > list
> > > > of what's missing from CRUDify so when we do the next version, it's
> > more
> > > > flexible and meets more needs out of the box.
>
> > > > >       :-)
> > > > > /Jeppe
>
> > --
> > 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<liftweb%2Bunsu...@googlegroups.com >
> > .

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

> mail/google talk: kev.lee.wri...@gmail.com
> wave: kev.lee.wri...@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda

[Jeppe Nejsum Madsen]

aw <ant...@whitford.com> writes:

> How about cleaning house?

Yeah, this sounds like A Good Thing :-)

> Like removing some things that you've rethought and don't care about
> backwards compatibility? - The Json that is pre-lift-json comes to
> mind. - The legacy log4j stuff that pre-dates the recent logger/slf4j
> work. I think the duplication is confusing to newbies.

At least this one is one the road map:
http://www.assembla.com/spaces/liftweb/tickets/345

> What about making Lift compliant with 'Elements of Scala Style'?

> http://www.codecommit.com/scala-style-guide.pdfFor example, on page 4: "Please note that the Lift convention of

> appending _? to boolean accessors is non-standard and not used outside
> of the Lift framework."

I'm not sure if this is a goal. I kinda like the _? convention.....

> I'm very keen to see a Servlet 3.0 version of Comet.
>
> Support for joda-time, scalaj-time or javax.time. After discovering a
> serious bottleneck in java.util.Date, I am a convert to joda-time, and
> java.time is practically an attempt to standardize it using a JSR.
> Support in Mapper, Record, Json, REST, etc. would be nice.

Indeed.

[...]

> Some handy dandy cache helpers (leverage ehcache's self populating
> cache mechanism, for example). Being able to neatly cache security
> privileges, database results, configuration settings, etc.

There's some simple stuff already, have a look at {Request|Session}Memoize....

/Jeppe

[Timothy Perrett]

Agreed - this is a Lift convention and would cause massive, massive breaking changes to remove it. Sorry, its not going to happen.

[Timothy Perrett]

We've also discussed this before and it didn't get any traction as the goal was to create a higher level JS api that had a distinctly Scala feel to it.

If you have any particular thoughts in this area though, by all means do share them

Cheers, Tim

[Timothy Perrett]

Cappuccino is a JS framework that runs on Obj-J. The only real implementation specification implementation that could be done there is to right an objective-j client for Lift's comet mechanism so that its 1st order with Capp rather than bridging through JS.

Cheers, Tim

[Jeppe Nejsum Madsen]

>> >    - Further refinement of mixin traits for field and form validation
>> > along
>> >    with integration of client side validation
>>
>>     - Enhanced, composeable, extendable CRUDify that utilize the above
>
> I did CRUDify in a day to settle a bet with myself.  I'd love to get a list
> of what's missing from CRUDify so when we do the next version, it's more
> flexible and meets more needs out of the box.

I realize building CRUD apps is probably not one of Lift's core
strengths. But from personal experience (and reading this list) it
seams like it's something many people have to do anyway :-)

CRUDify comes in real handy, as it's a great way to build something
useful really fast. Unfortunately, I feel that once you need to move
beyond what's provided, you have to start from scratch since CRUDify
is not very extensible. So, without further ado here's some stuff I
would like to see (some of this I've already got working in our app)

The list view:
- Better control over which fields to display (list vs form)
- Ability to mixin new layout & functionality (we have: client side
sorting, paging and searching, zebra layout, column sizing, footer
with column total etc)
- Mixins to define list actions (ie standard read,edit, delete)
- Mixins to define global actions (ie create)

The form views
- Better control over layout, default as today with list of fields,
but ability to specify custom layout (ie to provide grouping of
fields, maybe tab pages etc)
- Mixins for changing field rendering (required fields, labels,
validation errors, field help, field hints)
- Mixins for adding functionality on submit

I envision CRUDify will just be composed by adding a lot of small
traits that provides some default functionality (same as today).
Gradually the user can add more specialized functionality so that
eventually you end up with you own MyAppCRUDify that is used
throughout your application and renders everything the way you want.

/Jeppe

[Kevin Wright]

+1 on each and every one of these points.

What *is* the deal with _? anyhow? 

Perhaps someone forget to invite me to the competition where we "Invent _even more_ ways that Scala can (ab)use the underscore character!" 

I do hope that it isn't just Ruby-chasing, because we're better than that...

[David Pollak]

Both _? and _! are important idioms in Lift and they are not going to change (nor are they Ruby-chasing).

First, the "_" is necessary to separate alpha-numeric characters from symbols.  It's necessary.

Second, the "?" means "question" that can have a true/false answer.  It's no different than "is" in Java, but much more clear.  The "!" means "think about what you're doing before you call this" (it was a mistake to add it to the delete_! method on Mapper, but that's something else entirely).

I spent a fair amount of time with Apple employee #1 who was part of the Mac UI team, did the HyperCard UI and helped design HyperScript, and gave substantial feedback on Mac toolbox APIs.  We talked about naming conventions, etc. and the flexibility Scala brings to the table.  Bill's feedback on the "?" and "!" were strongly positive and that's why they're part of Lift.

While I respect the Novell team and the coding conventions they came up with, I strongly disagree with any deprecation of ? or !

 

Perhaps someone forget to invite me to the competition where we "Invent _even more_ ways that Scala can (ab)use the underscore character!" 

I do hope that it isn't just Ruby-chasing, because we're better than that...

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--

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.

[David Pollak]

On Tue, Jun 8, 2010 at 12:18 AM, ngocdaothanh <ngocda...@gmail.com> wrote:

Sorry, but is there room for non-functional features, like
documentation?

The question is features.  Documentation is not a feature.

In terms of documentation, Lift has a higher comment-per-line ratio than Rails.

But more importantly, documentation is something that can come from the community.  We've got a wiki.  You (and everyone who gets answers to questions) can update it.  Lift is open source and all of the folks who maintain the code are doing it without getting paid to do so.  The quickest and best way to contribute back to the project is to document things as you discover them.

 

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

[DChenBecker]

Just to throw this out there, I did my own version of CRUDify for
LiftTicket a while back. I don't think that it's necessarily tons
better, but I took a different approach for access control based on
partial functions instead of method defs. It also allows for synthetic
fields outside of the mapper types on a particular class:. Basically,
I was trying to make things more flexible while centralizing the
access control parts of CRUD.

http://github.com/dchenbecker/LiftTicket/blob/master/src/main/scala/org/liftticket/liftticket/model/CRUDLike.scala

There's an example of usage here:

http://github.com/dchenbecker/LiftTicket/blob/master/src/main/scala/org/liftticket/liftticket/model/Module.scala

Derek

On Jun 7, 1:35 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> On Mon, Jun 7, 2010 at 12:32 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>
>
>
>
> > Sounds good! A few comments inline
>

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

[Kevin Wright]

I do understand the logic behind these conventions, and the need for the underscore here (mixed identifiers, as per the scala spec).

But I still have concerns, especially when the notation is considered with regards to Scala.

• _ is already heavily overloaded, Lift in particular uses it a LOT when passing around function handles and for varargs.  The opportunities for misunderstanding are plentiful.
  
  
• _ also looks a lot like a space when scanning quickly, this risks confusion in a Language where whitespace can be semantically significant (think operator notation)
  
  
• suffixing "_?" is logically equivalent to prefixing "b", I'd call it "reverse hungarian notation" but that always makes me think of "reverse polish" - a totally unrelated concept.  The perils of embedding type information in naming conventions are already well known.
  
  
• ! does serve as a warning for me.  But as a warning that actors are around and I should follow the correct message semantics instead of calling methods directly.  Lift's overloaded usage of ! therefore forces a higher cognitive overhead onto developers, especially given that _ can look like whitespace
  
  
• The convention breaks with Scala idioms, where the first part of mixed identifiers is typically suppressed in usage.
  Consider "unary_-" as used in "println(-2.3)", or "prop_=" as used in "prop = 42" 

To be fair, most of this is caused the underscores and not the !/? characters.  In other Languages the underscore is not so likely to cause confusion, but in Scala it _is_ at high risk of doing so.

[dirk husemann]

I quite like lift's use of xxx_? and xxx_! Even picked it up for our own code base.

"it's all a matter of taste, mumbled the ape and took a bite out of the soap bar"

On Jun 9, 2010 1:24 PM, "Kevin Wright" <kev.lee...@gmail.com> wrote:

On 8 June 2010 16:23, David Pollak <feeder.of...@gmail.com> wrote:
>
>
>

> On Tue, Jun 8, 201...

I do understand the logic behind these conventions, and the need for the underscore here (mixed identifiers, as per the scala spec).

But I still have concerns, especially when the notation is considered with regards to Scala.

• _ is already heavily overloaded, Lift in particular uses it a LOT when passing around function handles and for varargs.  The opportunities for misunderstanding are plentiful.
  
  
• _ also looks a lot like a space when scanning quickly, this risks confusion in a Language where whitespace can be semantically significant (think operator notation)
  
  
• suffixing "_?" is logically equivalent to prefixing "b", I'd call it "reverse hungarian notation" but that always makes me think of "reverse polish" - a totally unrelated concept.  The perils of embedding type information in naming conventions are already well known.
  
  
• ! does serve as a warning for me.  But as a warning that actors are around and I should follow the correct message semantics instead of calling methods directly.  Lift's overloaded usage of ! therefore forces a higher cognitive overhead onto developers, especially given that _ can look like whitespace
  
  
• The convention breaks with Scala idioms, where the first part of mixed identifiers is typically suppressed in usage.
  Consider "unary_-" as used in "println(-2.3)", or "prop_=" as used in "prop = 42" 

To be fair, most of this is caused the underscores and not the !/? characters.  In other Languages the underscore is not so likely to cause confusion, but in Scala it _is_ at high risk of doing so.

 
>
>  
>>
>> Perhaps someone forget to invite me to the competition where we "Invent _even more_...

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com

wave: kev.lee...@googlewave.com...

[Will Sargent]

I would really like to see a Sass / HAML style implementation in Lift.  Scalate is very pretty, and I've been pleasantly surprised by how comfortable HAML is.

Will.

--

[Timothy Perrett]

Errr, thats already been integrated... or is that not what you meant?

[Naftoli Gugenheim]

What do you mean by streamlined?

[Naftoli Gugenheim]

Could you elaborate on why the JS DSL wasn't successful?

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

[Naftoli Gugenheim]

 

> What about making Lift compliant with 'Elements of Scala Style'?

How about making Lift more compliant with its own style? :)

Btw was the github wiki page on conventions copied to assembla? Does anyone update it?

[tommycli]

I would put a vote against the easy peasy DSL. I don't think people
are going to use Lift to build simple fast stuff anytime soon.
Deployment itself is already such a higher barrier than PHP/CGI that
an 'easy' DSL isn't going to be a draw. Lift's advantage is in doing
the hard stuff.

On CRUDify - I would really like to see better ORM integration with
the View/snippet mechanism. It's such an often use case to need to
retrieve a single URL paramed object for a view, I'm surprised it's
not built in. I ended up writing my own view which does:

def viewObj(oid: String) = doWithObj(oid, o=> {
rest of body
})

where the oid is passed in through the viewDispatchPF. I think this
should be made easier.

I realize a big obstacle here is that we have 3 different ORMs...
maybe define a common interface that each of them implements would be
a good idea.

Also, the fact that you have to use a totally different mechanism for
replying with HTML vs. a JsonResponse or a PlainTextResponse is kind
of clunky. Should we really be requiring users to use custom dispatch
for that sort of thing? One alternative would be to add a LiftResponse
subclass that goes through all the templating/snippet processing... so
someone could potentially just put all the dispatches through
customDispatch.

[Jeppe Nejsum Madsen]

Naftoli Gugenheim <nafto...@gmail.com> writes:

> What do you mean by streamlined?

[...]

>> I would like to see the Mapper/Record/Squeryl (and maybe JPA) stuff
>> streamlined.

[...]

Currently there's quite a few methods for persistence, both working and
work in progress. Some things (e.g CRUDIfy) only works with Mapper
etc. I would like to see this unified to e.g. Record so everything
persistence in Lift has the same interface (where possible) and same
level of support in Lift.

/Jeppe

[Paul Fuller]

Does sbt have support from any of the IDE's and CI implementations
yet ?

My concern is this is something that might be lost by moving away from
Maven, although getting away from that xml hell is a good step.

[Timothy Perrett]

James Strachen has blogged and written articles on using SBT from within InteliJ... so yeah, its totally possible.

From a book writers perspective, I was keen to not use an IDE because that creates a tie-in to a specific platform that the reader might not want to use (and making the instructions less agnostic). At least the command line is a universal environment. I only use 4 SBT commands in the whole book: update, ~compile, jetty-run and jetty-stop... any developer should be able to follow those basic instructions IMO.

Cheers, Tim

[Esko Luontola]

On Jun 10, 11:16 am, Paul Fuller <paul.fuller...@googlemail.com>
wrote:

> Does sbt have support from any of the IDE's and CI implementations
> yet ?

I'm working on a plugin for IntelliJ IDEA (for just executing sbt
commands such as test-compile - for dependency management I rely on
IDEA's Maven integration). It's still very early, but can be used with
some manual configuration: http://plugins.intellij.net/plugin/?idea&id=4991

[Naftoli Gugenheim]

I think there is already an sbt classpath container plugin for eclipse, and there's another sbt plugin that's a work in progress somewhere on assembla.

[Kevin Wright]

I believe the current sbt solution for eclipse is to use the ivy classpath container, but it's essentially the same thing :)

--
Kevin Wright

[Marius]

Not really sure what the point of this discussion really is.
Ironically or not, naming is probably one of the most controverted
things in software and there will always be pros and cons. AFAIK
historically _? and _! were not really impediments in writing Scala
code based on people's feedback.

On Jun 9, 2:45 pm, dirk husemann <husem...@gmail.com> wrote:
> I quite like lift's use of xxx_? and xxx_! Even picked it up for our own
> code base.
>
> "it's all a matter of taste, mumbled the ape and took a bite out of the soap
> bar"
>

> On Jun 9, 2010 1:24 PM, "Kevin Wright" <kev.lee.wri...@gmail.com> wrote:

>
> On 8 June 2010 16:23, David Pollak <feeder.of.the.be...@gmail.com> wrote:
>
> > On Tue, Jun 8, 201...
>
> I do understand the logic behind these conventions, and the need for the
> underscore here (mixed identifiers, as per the scala spec).
> But I still have concerns, especially when the notation is considered with
> regards to Scala.
>

>    - _ is already heavily overloaded, Lift in particular uses it a LOT when

>    passing around function handles and for varargs.  The opportunities for
>    misunderstanding are plentiful.
>

>    - _ also looks a lot like a space when scanning quickly, this risks

>    confusion in a Language where whitespace can be semantically significant
>    (think operator notation)
>

>    - suffixing "_?" is logically equivalent to prefixing "b", I'd call it

>    "reverse hungarian notation" but that always makes me think of "reverse
>    polish" - a totally unrelated concept.  The perils of embedding type
>    information in naming conventions are already well known.
>

>    - ! does serve as a warning for me.  But as a warning that actors are

>    around and I should follow the correct message semantics instead of calling
>    methods directly.  Lift's overloaded usage of ! therefore forces a higher
>    cognitive overhead onto developers, especially given that _ can look like
>    whitespace
>

>    - The convention breaks with Scala idioms, where the first part of mixed

>    identifiers is typically suppressed in usage.
>    Consider "unary_-" as used in "println(-2.3)", or "prop_=" as used in
>    "prop = 42"
>
> To be fair, most of this is caused the underscores and not the !/?
> characters.  In other Languages the underscore is not so likely to cause
> confusion, but in Scala it _is_ at high risk of doing so.
>
>
>
> >> Perhaps someone forget to invite me to the competition where we "Invent
>
> _even more_...
>
> --
> Kevin Wright
>

> mail/google talk: kev.lee.wri...@gmail.com
> wave: kev.lee.wri...@googlewave.com...

[Will Sargent]

It looks like Scalate is in 2.0, which is good.  I will poke at it.

The Ruby version of HAML has a CSS processor called Sass built into it that lets you set up templates very quickly.  Something similar in Lift would be excellent.  There was an email about it a while back:

http://www.mail-archive.com/lif...@googlegroups.com/msg06228.html

but it doesn't seem like the github repository is active.

Will.

[Timothy Perrett]

Have you tried mailing Derek listed in that thread? Maybe he just moved the repo someplace? Looks like he unregistered from github tho.

Cheers, Tim

[Lincoln Stoll]

Looks like he just renamed his account

http://github.com/derekjw/scala-sass-compiler

[aw]

What about adding "excellent support" for HTML5 features?
Thinking specifically about adding clever implementations to manage
things like the Application Cache, manage WebGL, WebSockets,
GeoLocation, etc.
Some of these features could be handled in a way where there is a pre-
HTML5 fallback that perhaps manages more stuff on the server side
instead of the client.

Just brainstorming...

[David Pollak]

On Wed, Jun 9, 2010 at 7:35 PM, tommycli <tomm...@ucla.edu> wrote:

I would put a vote against the easy peasy DSL. I don't think people
are going to use Lift to build simple fast stuff anytime soon.
Deployment itself is already such a higher barrier than PHP/CGI that
an 'easy' DSL isn't going to be a draw. Lift's advantage is in doing
the hard stuff.

On CRUDify - I would really like to see better ORM integration with
the View/snippet mechanism. It's such an often use case to need to
retrieve a single URL paramed object for a view, I'm surprised it's
not built in. I ended up writing my own view which does:

def viewObj(oid: String) = doWithObj(oid, o=> {
 rest of body
})

Okay.. on one hand you argue that we shouldn't make stuff easier and then you argue that we should.  Most of what you're asking for is going to be covered by a set of DSLs that extends Screen and make it easier to do form building for OR and non-OR applications.
 

where the oid is passed in through the viewDispatchPF. I think this
should be made easier.

I realize a big obstacle here is that we have 3 different ORMs...
maybe define a common interface that each of them implements would be
a good idea.

Also, the fact that you have to use a totally different mechanism for
replying with HTML vs. a JsonResponse or a PlainTextResponse is kind
of clunky.

Except it's not.  It creates a clean separation from building a web application vs. building web apis.  A web application vends a page containing complex state and lots of components (entities that know about themselves, but not necessarily the whole page.)  A web API responds to a single request.  Keeping Lift as far away from being a front-controller/MVC framework as possible has been a goal of mine and it pays off handsomely when responding to questions like "how do I put 4 different components on a page and swap them out dynamically."

With all that being said, if you want to treat Lift as a front-controller framework, you're welcome to do so.  You can use Loc.EarlyResponse to kick back a non-HTML page for a URL if the request meets certain criteria.  Alternatively, you can use the RestHelper mechanism to build routes and respond to HTML requests by running a given template for the request.  Both are simple additions (in the order of a few hundred lines of code for the abstractions) that you can build for your own use or for the community.  Me... I'm pretty staunchly in camp of separating the concept of web application from the concept of web API.
 

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

--