Timothy Perrett

author
+ Follow
since Nov 21, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Timothy Perrett

Great :-)

You're more than welcome guys; it was a pleasure to answer your questions. Even if you don't wind up using Lift, I hope the ideas within the project have an affect on the way you do web development.

Cheers, Tim
12 years ago

Hussein Baghdadi wrote:Is ScalaQuery the equivalent to .NET LINQ?



I'm not hugely familiar with link, but scalaquery only works with RDBMS, not say, XML files or whatever which I think LINQ does?
12 years ago

Bear Bibeault wrote:As we know, HTML5 can be written using well-formed markup or non-well-formed markup. So the non-well-formed formats of HTML5 would cause problems?

Just curious: why does Lift care about non-Lift markup? Why does it not treat non-Lift-markup as opaque template text?



No not at all. The HTML5 parser handles that without issue. If there are any problems, there down to the parser and not Lift (the parser is: http://about.validator.nu/htmlparser/).

Lift treats its templates as XML because it allows us to do some much more sophisticated things within the template handling rather than simply munging strings around which is a nightmare. Additionally if you know that all your template code is XML, you have to then be explicit about passing unparsed data into the output stream which makes it harder for developers to unwittingly add security holes into their apps, as they have to explicitly say "this ABC here is Unparsed".

Hope that helps
12 years ago

Bear Bibeault wrote:I'm all ears -- can you give a capsule summary of the ScalaQuery approach and what makes ScalaQuery so awesome?

(DB access has always been a thorn in my side, so I'm always looking for better ways.)



Database queries using monad comprehensions... what's not to like :-D Here's an example:

for {
c <- Coffees
s <- c.supplier
_ <- Query groupBy s.id
} yield s.name.min.get ~ c.name.count

Super, super nice as its all typesafe, and if it doesn't compile, the query wouldn't run. Essentially anything that compiles is a valid query.

12 years ago

Bear Bibeault wrote:

Timothy Perrett wrote:Gems == Jars :-) It's that simple.


I like simple.

I assume that this means that Lift/Scala can leverage* other JVM-based libraries and "gems" written in other JVM languages? (Java, Groovy, et al...)



In theory it could; i've never tried calling anything but Java from Scala. To be honest, after you've programmed Scala for a while, calling Java APIs feels ugly with all their mutability and other nasty properties... you just want to rewrite everything into native, immutable APIs :-D
12 years ago

Bear Bibeault wrote:

Timothy Perrett wrote:Personally I avoid JPA like the plague.


So you are saying that the Lift/Scala ecosystem has numerous DB access choices and that you can pick the one that best suits your project or programming style?



Yup this is exactly what I'm saying.

Bear Bibeault wrote:

Timothy Perrett wrote:Personally I avoid JPA like the plague.


Is there one that's similar to Play's ORM approach? Is there an even simpler (as in straight-forward) choice? Which would you use for a RESTful web service that's mostly a glorified CRUD layer?



Similar to AnORM? I don't think so. Personally I don't like that kind of approach as I prefer something typesafe like ScalaQuery which is the absolute awesome :-)

Cheers, Tim

12 years ago

Mohamed Sanaulla wrote:Agree, making it more complicated would only lead to making it difficult to use. But I believe there should be a plugin system in place? Like in Rails I can make use of any gem to add any new capability with my application.



Gems == Jars :-) It's that simple.

Lift has a boot phase and you can register any code you want there, so there isn't really a need for a plugin system per-say, as it just needs to be on the class path. Idiomatically, your "plugin" has a init object that you call from boot like Shiro.init in my Lift-Shiro integration: https://github.com/timperrett/lift-shiro

Cheers, Tim
12 years ago

Mohamed Sanaulla wrote:Timothy, are there any features you feel are missing from Lift framework which you wish should be a part of Lift?



I would actually prefer to remove features as it happens. Ideally i'd like to kill off everything but the core web aspects and move the database and record stuff into community maintained libraries. Projects tend to grow and grow over time and I think its really healthy to cut stuff out, not add more :-)

Cheers, Tim
12 years ago

Vijitha Kumara wrote:Hi Timothy,

The video you linked talk much about support/usage of the view. That's perhaps it's more view oriented. What kind of support is available for other back end development for things like asynchronous processing, transaction management etc...? Are there any other libraries available or Lift itself provide them.

Thanks,



Hi there,

What kind of asyc processing are you talking about? If you mean for general business process then you're better off using Akka for that. Lift is a web framework and not a huge amount more (it has other parts, but thats not the focus). For async processing, database handling and all the other types of tools you might want the scala eco-system does an excellent job of providing for those.

If however you meant asyncronus rendering, or parallel rendering of web views... then sure, Lift supports those really easily.

Tim
12 years ago

Bear Bibeault wrote:I'm well past the age where I'll take the time to learn a new language "just because it's cool". So I've been waiting for a good reason to look at Scala before I dive into the pool.

Lift may be that reason.

So, author Timothy Perrett, what would you consider the best resource for a seasoned developer who's used dozens of languages in his career, but has been focusing on Java and JavaScript in recent years?

Others can chime in with their choices as well, but I'm really interested in hearing Timothy's choices.



More broadly, i'd suggest two books:

1) Programming in Scala: this is essentially the canonical book for learning Scala, written by Odersky himself. It's surprisingly accessible and serves as a good reference for any budding scala dev - http://www.amazon.com/Programming-Scala-Comprehensive-Step-Step/dp/0981531644

2) Scala in Depth: PinS will only get you so far, and after a few months of programming you might want to step up to the more advanced things that are possible with Scala... many of which come from pure functional programming and category theory. Josh's book is a great resource for learning those features and will be available in print version soon - http://www.manning.com/suereth/

Scala is very much a multi-paradigm language. You could pick it up today with just Java experience and program with it like it was Java without semi-colons. Likewise, people from Haskell can also pick it up and do some very advanced type-level programming. There's no point learning Scala "because its cool"... the real reason to learn it is because its a powerful language that will give you easy entry into the awesome that is functional programming. Many people find haskell to be overwhelming, so being able to program imperatively and take functional features like HOFs and type classes where you want them is really rather convenient.

Hope that helps
12 years ago

Bear Bibeault wrote:Timothy, in this topic you linked to an informative video on Lift.

In it, you state that Lift's Ajax support leverages underlying JavaScript libraries including jQuery. Such abstraction is great, but is there any issue with using jQuery directly in on-page script to do things that are strictly client-side activities? Or does direct use of jQuery in the templates interfere with Lift's mechanics?



Not at all actually. Its essentially a "take it or leave it" abstraction. It's primary goal is to abstract away parts of Lift plumbing so people can use different libraries without interference from some internally mandated JS lib (resulting in clashing operators etc)... meaning that if you use YUI, Lift will use YUI automatically for its Comet and AJAX actions. You can happily write all the JS code you want in regular JQuery, CoffeeScript or whatever and that won't be affected by Lift at all. You can even have Lift dynamically call your own JS code if you want as well.

Hope that helps

Tim
12 years ago

Bear Bibeault wrote:One of the things I really like about Play!, and the reason used I used it for a handful of projects despite the many things that I don't like about Play!, is its fairly seamless integration with Hibernate/JPA that factors away most of the pain of dealing with databases.

How does Lift fare in this space?

Nothing drives me crazier than having to deal with JPA and Hibernate nonsense.



Personally I avoid JPA like the plague. There is support for a more reasonable abstraction of working with JPA (chapter 13 in LIA), but you very much still know you're working with JPA. It's essentially a wrapper on JPA to give the API more of a Scala feel. Depending on how much JPA you need to use, this may or may not eliminate some of the pain.

Lift does ship with its own database layers, but you are in no way bound to use them. I typically don't use Mapper (lifts ORM) at all, rather, I use ScalaQuery when I need to interact with RDBMS. There are several very excellent database abstractions in the Scala eco-system, so it doesn't pay to be tied by the one that a particular framework brings to the table (that goes for both Lift and Play!)

Cheers, Tim
12 years ago

Mohamed Sanaulla wrote:I dont know about Lift, but for Scala there's a plugin for eclipse Scala IDE. May be IntelliJ should also have.



Sure, Lift is just Scala, so you don't need any special plugins to use it. Theres good support in JetBrains IDEA, Eclipse and several of the text editors integrate with ENSIME to provide IDE-like functionality for Scala. The templates are just HTML/XML so supported by nearly all editors out there.

Cheers, Tim
12 years ago

Bear Bibeault wrote:Not sure yet...

Does Lift expect non-Lift markup to follow certain rules? Or is it like JSP where anything that's not a JSP element is simply template text that's sent verbatim in the response?

I'm thinking of use cases like custom attributes and the like.



Provided the XML being sent to the browser passes the (for example) XHTML parser (meaning all tags are properly closed), then you can essentially do whatever you want. Lift will automatically sanitise the content by escaping entities etc etc, but otherwise provided it passes parsing you should be fine.

Thanks, Tim
12 years ago
Good question. In 2010 the HTML5 situation was more confussed, but these days Lift has full parser support for all the regular HTML, XHTML and HTML5 formats (where "support" is built in parsing and transformation if desired)

Hope that helps!

Tim
12 years ago