[Lift] Re: Menu widget

[Derek Chen-Becker]

Do you have lift-widgets module as a dependency in your pom.xml?


  net.liftweb
  lift-widgets
  1.1-SNAPSHOT


That's needed to get the dropdown widget code.

Derek

On Thu, Apr 2, 2009 at 3:13 PM, DavidV  wrote:

>
> I posted this yesterday but I haven't seen it appear yet...sorry if it
> is here twice.
>
> I downloaded the scripts separately because I didn't know how to
> update my repository/library to include the MenuWidget class and the
> appropriate .js and .css files.  I tried running "mvn install" on my
> webapp, but it didn't download those new files.
> I fixed the problem with my .css file so it compiles now, however I'm
> still not getting the nice stylish superfish navbar.  Instead, I'm
> getting a vertical bulleted list of links to my different pages.  I
> think it's a problem with my template.  Here are the relevant
> sections:
>
> http://www.w3.org/1999/xhtml"; xmlns:lift="http://
> liftweb.net/">
>  
>
>
>
>
>My WebApp  
>
>
>
>

[Lift] Re: Need for lightweight JPA archetype

[Derek Chen-Becker]

I agree. The cost of creating the archetypes is relatively low, so having
variations on a theme would be nice.

Derek.

On Thu, Apr 2, 2009 at 9:27 AM, Timothy Perrett wrote:

>
> I guess if your deploying into an "enterprise container", then EAR is
> fine, however if your deploying into Jetty then you don't have the
> possibility of deploying to EAR. I just think that having the
> possibility of creating either a merged project or a split project is
> important as JPA brings things to the table some great features that
> people should be able to use however they want.
>
> IMO, the archetypes are enablers - I know we could create this stuff
> manually, but we want to enable people to be productive quickly.
>
> Thoughts?
>
> Tim
>
> On Apr 2, 3:06 pm, Derek Chen-Becker  wrote:
> > Works for me :)
> >
> > On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett  >wrote:
> >
> >
> >
> > > I 100% see why you want a seperate module for persistance, but
> > > workflow wise I've found JPA a lot more productive if it's in the lift
> > > app as it means you don't have to keep deploying the JAR into your
> > > local repo.
> >
> > > Perhaps
> >
> > >  lift-jpa-archetype-blank-split
> > >  lift-jpa-archetype-blank-consolidated
> >
> > > Thoughts?
> >
> > > Tim
> >
> > > On Apr 2, 7:33 am, Derek Chen-Becker  wrote:
> > > > I thought I had sent out an email on the list earlier asking what
> people
> > > > would want to see in such an archetype. As a base, probably a master
> POM
> > > > with a module for the persistence unit and a module for the Lift side
> of
> > > > things. The persistence unit could have a skeleton persistence.xml in
> the
> > > > right place but otherwise be empty. The Lift side could have the
> basic
> > > Boot
> > > > and perhaps a Model class set up with a placeholder persistence
> setup.
> > > > Thoughts?
> >
> > > > Derek
> >
> > > > On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett
>  > > >wrote:
> >
> > > > > Glad im not the only one ;-)
> >
> > > > > On Apr 1, 11:15 pm, Viktor Klang  wrote:
> > > > > > Timmy,
> >
> > > > > > yeah, I can see that coming in handy.
> >
> > > > > > Cheers,
> > > > > > Viktor
> >
> > > > > > On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett
>  > > > > >wrote:
> >
> > > > > > > Guys,
> >
> > > > > > > Do people see room for a blank JPA archetype just like we have
> > > blank
> > > > > > > and basic of normal lift archetypes?
> >
> > > > > > > IMO, whilst its great having the basic one for learning and
> > > examples,
> > > > > > > having something thats a workable starting point without having
> to
> > > > > > > remove code etc would be helpful.
> >
> > > > > > > I appreciate this is a bit lazy - but i don't think it would
> take
> > > much
> > > > > > > work and would provide a neat solution
> >
> > > > > > > Thoughts?
> >
> > > > > > > Tim
> >
> > > > > > --
> > > > > > Viktor Klang
> > > > > > Senior Systems Analyst
> >
>

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

[Lift] [Bug] liftAjax.js generation bug in case of LiftRules.enableLiftGC = false

[nau]

Hi there,

There is a bug in ScriptRenderer.scala I've described here:
http://liftweb.lighthouseapp.com/projects/26102/tickets/31-bug-liftajaxjs-generation-bug-in-case-of-liftrulesenableliftgc-false#ticket-31-1.

I've got a quick fix for it but I don't think it's the best one
(sorry, can't provide normal patch now, I'm on windows):

ScriptRenderer.scala

function addPageName(url) {
  return url.replace('""" + LiftRules.ajaxPath + """', '""" +
LiftRules.ajaxPath + liftPage + """);
}

function lift_actualAjaxCall(data, onSuccess, onFailure) {
""" +
LiftRules.jsArtifacts.ajax(AjaxInfo(JE.JsRaw
("data"),
"POST",
 
LiftRules.ajaxPostTimeout,
false,
"script",
Full
("onSuccess"), Full("onFailure")))+
"""
}

""" +
LiftRules.jsArtifacts.onLoad(new JsCmd() {def
toJsCmd = "lift_doAjaxCycle()"}).toJsCmd)

  val liftPage = if (LiftRules.enableLiftGC) "/'+lift_page" else
""
--

One more. I've found inconsistent statements in Liftweb book (pdf
compilation master-20090309 from github). I'm not sure wheather it
still exists but anyway:
paragraph 3.4 states:
"3. Check to see if the request should be handled by a View. This is
covered in section
3.6
4. If the request is not handled by a View, find a template that
matches and use it. We’ll
cover templates in section 3.5"

but paragraph 3.6 states:

"In either case, View lookup and dispatch is done after template
resolution, so templates take priority."

Cheers,
Alex Nemish

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

[Lift] Re: Menu widget bugginess

[Derek Chen-Becker]

Have I mentioned my extreme dislike for IE? I wonder if there's anything we
can do from the widget side to, say, explicitly add z-order...

Derek

On Thu, Apr 2, 2009 at 9:59 AM, Charles F. Munat  wrote:

>
> Hmmm. Your google-fu is very powerful! "The fix is so simpel"!
>
> I think this will probably work in this instance, but I'm pretty sure it
> doesn't work in every case, e.g. form inputs... else why the bother of
> using iframes via bgiframe.js? But for the Widgets examples, it looks
> like plain old divs, so I'll check it out when I get a break.
>
> Thanks!
>
> Chas.
>
> Viktor Klang wrote:
> > Hello Chas,
> >
> > Can it be related to this:
> > http://webdemar.com/webdesign/superfish-jquery-menu-ie-z-index-bug/
> >
> > Cheers,
> > Viktor
> >
> > On Thu, Apr 2, 2009 at 3:40 AM, Charles F. Munat  > > wrote:
> >
> >
> > I'm running the Lift Menu widget on my Mac via mvn jetty:run, then
> > looking at it in IE Tester running in Windows XP Pro in a VMWare
> virtual
> > machine on a Fedora 9 box on the same network. (Whew.)
> >
> > In IE 8 it works fine.
> >
> > In IE 7 and IE 6, on the CalendarWeekView and CalendarDayView pages,
> the
> > third submenu link slides under the week or day view of the calendar
> and
> > becomes inaccessible (and invisible as well). This is a typical
> problem
> > with these piece of shit browsers that every self-respecting human on
> > this planet should have rejected long ago... whoops. Did I write that
> > out loud?
> >
> > The fix involves bigiframe.js, which I see is included in the toserve
> > directory and on the page, so I'm not really sure why this problem is
> > occurring. Isn't that what bigiframe.js is supposed to solve?
> >
> > Chas.
> >
> >
> >
> >
> >
> >
> > --
> > Viktor Klang
> > Senior Systems Analyst
> >
> > >
>
> >
>

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

[Lift] Re: Proposed URL Shortening widget

[Timothy Perrett]

Hey Jorge,

Im not sure I 100% follow what your saying - are you proposing
creating a widget that actually has a shortening algorithm? IMO, isnt
it better to not re-invent the wheel and use an existing service?
(take advantage of their short domain names etc)

What are your thoughts on the blocking vs non-blocking thing?

Cheers, Tim

On Apr 2, 9:48 pm, Jorge Ortiz  wrote:
> What about easily turning any lift app into a url shortener service?
>
> Wouldn't be too hard...
>
> Granted, some services (bit.ly) add statistics, visualization, conversation
> tracking, etc. which aren't just url shortening.
>
> --j
>
> On Thu, Apr 2, 2009 at 12:13 PM, Tim Perrett wrote:
>
>
>
> > Guys,
>
> > I've been contemplating doing this for a while and am now finding
> > myself with a bunch of free time tomorrow and a need to write some
> > code.
>
> > So, I want to make a widget that shortens URL's in an extendable
> > way... Im thinking of having something like:
>
> > trait URLReductionProvider { ... }
>
> > object TinyURL extends URLReductionProvider
> > object IsGd extends URLReductionProvider
> > object BitLy extends URLReductionProvider
>
> > You get the general idea...
>
> > So, im thinking of implementing the actual URL fetching stuff as a
> > partial function so that users could do:
>
> > def reductionResult = {
> >  case Full(result) => // result is the URL, insert into database etc
> >  case _ => // something went wrong
> > }
>
> > My question is however, if i make this actor based, could someone
> > implement it so rather than writing there URL to database in a
> > separate thread to the main one, would it be possible for them to say,
> > use a JsCmd and return that to update the browser? Im guessing not
> > unless it was a CometActor right.
>
> > This then got me thinking, do you guys thing this is worth doing actor
> > based, or is it just ok to make a blocking call to the provider?
> > (tinyurl or is.gd etc)
>
> > Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Menu widget

[DavidV]

I posted this yesterday but I haven't seen it appear yet...sorry if it
is here twice.

I downloaded the scripts separately because I didn't know how to
update my repository/library to include the MenuWidget class and the
appropriate .js and .css files.  I tried running "mvn install" on my
webapp, but it didn't download those new files.
I fixed the problem with my .css file so it compiles now, however I'm
still not getting the nice stylish superfish navbar.  Instead, I'm
getting a vertical bulleted list of links to my different pages.  I
think it's a problem with my template.  Here are the relevant
sections:

http://www.w3.org/1999/xhtml"; xmlns:lift="http://
liftweb.net/">
  




My WebApp  

[Lift] Re: The Lift 1.1 list

[Xavi Ramirez]

+10 for documentation effort.  Speaking from the noob perspective, the
documentation is the biggest barrier to entry for Lift.  Currently
there are 3 places to get lift documentation:

-Get Started Tutorial
-Lift Book
-Lift Wiki

The first two sources are excellent, but the last one is bit lacking.
I think it'd be a big win if we can clean up the wiki.  Or, at the
very least we should get rid of obsolete articles/code.

Also, I feel it would be helpful if all the documentation was in one
location, opposed to separated into various in PDFs and webpages.

Just adding my two cents.

Thanks,
Xavi

On Thu, Apr 2, 2009 at 1:23 AM, Derek Chen-Becker  wrote:
> +10 on JodaTime. +1 on documentation effort, something I've got on my
> ever-growing TODO list...
>
> Derek
>
> On Wed, Apr 1, 2009 at 3:51 PM, Charles F. Munat  wrote:
>>
>> +1 Anything to get away from that damn Java Date/Calendar crap.
>>
>> Agreed on need to review API.
>>
>> Chas.
>>
>> Timothy Perrett wrote:
>> > I think your right Jorge... 2.8 brings some important changes that
>> > could quite possibly have some pretty significant breaking changes in
>> > the Lift API.
>> >
>> > I also agree with the JodaTime in record/field, sounds like perfect
>> > sense.
>> >
>> > Cheers, Tim
>> > >
>>
>>
>
>
> >
>

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

[Lift] Re: Proposed URL Shortening widget

[Jorge Ortiz]

What about easily turning any lift app into a url shortener service?

Wouldn't be too hard...

Granted, some services (bit.ly) add statistics, visualization, conversation
tracking, etc. which aren't just url shortening.

--j

On Thu, Apr 2, 2009 at 12:13 PM, Tim Perrett wrote:

>
> Guys,
>
> I've been contemplating doing this for a while and am now finding
> myself with a bunch of free time tomorrow and a need to write some
> code.
>
> So, I want to make a widget that shortens URL's in an extendable
> way... Im thinking of having something like:
>
> trait URLReductionProvider { ... }
>
> object TinyURL extends URLReductionProvider
> object IsGd extends URLReductionProvider
> object BitLy extends URLReductionProvider
>
> You get the general idea...
>
> So, im thinking of implementing the actual URL fetching stuff as a
> partial function so that users could do:
>
> def reductionResult = {
>  case Full(result) => // result is the URL, insert into database etc
>  case _ => // something went wrong
> }
>
> My question is however, if i make this actor based, could someone
> implement it so rather than writing there URL to database in a
> separate thread to the main one, would it be possible for them to say,
> use a JsCmd and return that to update the browser? Im guessing not
> unless it was a CometActor right.
>
> This then got me thinking, do you guys thing this is worth doing actor
> based, or is it just ok to make a blocking call to the provider?
> (tinyurl or is.gd etc)
>
> Cheers, Tim
> >
>

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

[Lift] Proposed URL Shortening widget

[Tim Perrett]

Guys,

I've been contemplating doing this for a while and am now finding
myself with a bunch of free time tomorrow and a need to write some
code.

So, I want to make a widget that shortens URL's in an extendable
way... Im thinking of having something like:

trait URLReductionProvider { ... }

object TinyURL extends URLReductionProvider
object IsGd extends URLReductionProvider
object BitLy extends URLReductionProvider

You get the general idea...

So, im thinking of implementing the actual URL fetching stuff as a
partial function so that users could do:

def reductionResult = {
  case Full(result) => // result is the URL, insert into database etc
  case _ => // something went wrong
}

My question is however, if i make this actor based, could someone
implement it so rather than writing there URL to database in a
separate thread to the main one, would it be possible for them to say,
use a JsCmd and return that to update the browser? Im guessing not
unless it was a CometActor right.

This then got me thinking, do you guys thing this is worth doing actor
based, or is it just ok to make a blocking call to the provider?
(tinyurl or is.gd etc)

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

[Lift] Re: The Lift 1.1 list

[Timothy Perrett]

Ok no worries - personally, I dont have any burning need for it right
this moment but I could certainly make serious use of it within the
next month.

Cheers, Tim

On Apr 2, 7:10 pm, David Pollak  wrote:
> Tim,
>
> It's on my backlog. Right now I'm working on a preso for a class I'm
> teaching today at Cal Berkeley.  Tomorrow is tax day and next week is a
> family vacation.  I'll try to get something to you.
>
> Thanks,
>
> David

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

[Lift] Re: Need for lightweight JPA archetype

[Timothy Perrett]

Probally between yourself and Derek in all honesty - I simply dont
have the time right now and my "lift time" and what I do with it has
other investments right now...

Derek might well be swamped with the book at the moment... so perhaps
there are not so many candidates as you think :-)

Crack on is what I say - make a branch, knock yourself out and then
post to the list before merging to master

Cheers, Tim

On Apr 2, 7:17 pm, "Charles F. Munat"  wrote:
> Yup. But there seem to be a few candidates...
>
> Timothy Perrett wrote:
> > Are you eyeing up for your first commit Chas? ;-)
>
> > The src of the JPA archetype is here:
>
> >http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb...
>
> > Cheers, Tim
>
> > On Apr 2, 6:02 pm, "Charles F. Munat"  wrote:
> >> Where is the code for these archetypes and how tricky is it to create them?
>
> >> Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Open Source Bridge Conference CFP (& Discount)

[David Pollak]

Folks,
It'd be great to see some Lift and/or Scala presentations at this
conference.

Thanks,

David

-- Forwarded message --
From: Keith Fahlgren 
Date: Thu, Apr 2, 2009 at 6:06 AM
Subject: [bayfp] Open Source Bridge Conference CFP (& Discount)
To: ba...@googlegroups.com



Seems like this conference might be an interesting addition to OSCON,
where Simon Peyton-Jones and Bryan O'Sullivan have given quite
compelling FP talks the last couple of years...

-- Forwarded message --
From: Reid Beels 

Open Source Bridge
http://opensourcebridge.org

Open Source Bridge is a new conference for developers working with
open source technologies. It will take place June 17-19 in Portland,
OR, with five tracks connecting people across projects, languages and
experience to explore how we do our work and why we participate in
open source. The conference structure is designed to provide
developers with an opportunity to learn from people they might not
connect with at other events.

Open Source Bridge is run entirely by volunteers who believe in the
need for an open source conference that focuses on the culture of
being an open source citizen, regardless of where in the stack you
choose to code. All proceeds from conference registration and
sponsorship go directly to the costs of the conference.

Our sessions and events will share in-depth knowledge about using,
creating and contributing to open source as citizens of a greater
community. You’ll find relevant information whether you write web apps
for the cloud, tinker with operating system internals, create
hardware, run a startup, or blog about technology.

We're still seeking proposals — and just extended the deadline to
April 10th — so submit yours before time runs out.

Some examples of our proposals so far: Brian Aker on Drizzle, a reboot
of MySQL designed “for the cloud”; Linux Kernel hacker Greg K-H about
how Linux manages development; Ward Cunningham, inventor of the wiki,
about what’s next in collaboration; Amber Case, an anthropologist
living in both the physical and virtual worlds, about Cyborg
Citizenship. (You can view all current proposals at
http://opensourcebridge.org/proposals/)

In addition to regular conference sessions, we will hold an
unconference day for free-form sessions, and host a 24-hour dedicated
“hacker lounge” at the top of the Portland Hilton. In addition to
hosting the hacker lounge, the Hilton has offered Open Source Bridge
attendees steeply discounted room rates, starting at $139/night.

The city of Portland is a great place to visit. It has a thriving
technical community, a love of all things open source and offers many
attractions for visiting geeks, including Powell’s technical books,
dozens of local brewpubs, and large greenspaces like Forest Park—all
accessible by mass transit.

Visit http://opensourcebridge.org/ to learn more about the conference,
see our session proposals, and register to attend.

Thanks!

PS: Interested in taking advantage of the user group discount code
that will allow user group members to register for $150? Enter
“osb4228” when you register to receive the discount.





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

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

[Lift] Re: The Lift 1.1 list

[David Pollak]

On Thu, Apr 2, 2009 at 10:09 AM, Bill Venners  wrote:

>
> Hi David,
>
> On Thu, Apr 2, 2009 at 9:28 PM, David Pollak
>  wrote:
> >
> >
> > On Thu, Apr 2, 2009 at 2:30 AM, Bill Venners  wrote:
> >>
> >> Hi David,
> >>
> >> On Thu, Apr 2, 2009 at 12:11 AM, David Pollak
> >>  wrote:
> >> > Folks,
> >> >
> >> > Improved testing framework and better testing support when running in
> >> > "test"
> >> > mode.
> >> >
> >> Can you elaborate on what your plans are for this?
> >
> > It's a goal, not a set of plans.  I'm expecting one of the committers
> would
> > take ownership and figure it out.  Wanna be a committer, take ownership,
> and
> > figure it out?
> >
> Ooh, I stepped in that one.


Yeah... don't you know the rule... get a good idea and you own it.  I'm just
the Tom Sawyer who's convincing the smart folks to white-wash my fence/build
Lift. ;-)


> The testing Lift apps is a good, real use
> case for both ScalaTest and Specs. I hope to meet with Eric Torreborre
> Monday. I'll talk with him about what's needed for Lift, as I think
> he's more familiar with its testing needs. I have definitely wanted to
> do some work with Lift so I can become more familiar with it as a web
> app framework, but just haven't had time yet. I'm gradually popping
> things off my stack of tasks, so I'll get there eventually.


Cool.  I think there's a need for a better way to test web apps in general
and to describe the state models so that they can be tested in a sane way.
 I just don't have a clue as to how to do it.  But... I think it ties in
with the JavaScript enhancements I want to see in 1.1.  Perhaps there's some
sort of state/logic combinator thingy that can emit client-side JS, sync
data, and be very testable.  Dunno... just ranting/flailing.


>
>
> Bill
>
> >>
> >> Thanks.
> >>
> >> Bill
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Git some: http://github.com/dpp
> >
> > >
> >
>
> >
>


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

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

[Lift] Re: Need for lightweight JPA archetype

[Charles F. Munat]

Yup. But there seem to be a few candidates...

Timothy Perrett wrote:
> Are you eyeing up for your first commit Chas? ;-)
> 
> The src of the JPA archetype is here:
> 
> http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb41b640/lift-archetype-jpa-basic
> 
> Cheers, Tim
> 
> On Apr 2, 6:02 pm, "Charles F. Munat"  wrote:
>> Where is the code for these archetypes and how tricky is it to create them?
>>
>> Chas.
> 
> > 

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

[Lift] Re: The Lift 1.1 list

[Bill Venners]

Hi David,

On Thu, Apr 2, 2009 at 9:28 PM, David Pollak
 wrote:
>
>
> On Thu, Apr 2, 2009 at 2:30 AM, Bill Venners  wrote:
>>
>> Hi David,
>>
>> On Thu, Apr 2, 2009 at 12:11 AM, David Pollak
>>  wrote:
>> > Folks,
>> >
>> > Improved testing framework and better testing support when running in
>> > "test"
>> > mode.
>> >
>> Can you elaborate on what your plans are for this?
>
> It's a goal, not a set of plans.  I'm expecting one of the committers would
> take ownership and figure it out.  Wanna be a committer, take ownership, and
> figure it out?
>
Ooh, I stepped in that one. The testing Lift apps is a good, real use
case for both ScalaTest and Specs. I hope to meet with Eric Torreborre
Monday. I'll talk with him about what's needed for Lift, as I think
he's more familiar with its testing needs. I have definitely wanted to
do some work with Lift so I can become more familiar with it as a web
app framework, but just haven't had time yet. I'm gradually popping
things off my stack of tasks, so I'll get there eventually.

Bill

>>
>> Thanks.
>>
>> Bill
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

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

[Lift] Re: The Lift 1.1 list

[David Pollak]

Tim,

It's on my backlog. Right now I'm working on a preso for a class I'm
teaching today at Cal Berkeley.  Tomorrow is tax day and next week is a
family vacation.  I'll try to get something to you.

Thanks,

David

On Apr 2, 2009 9:07 AM, "Timothy Perrett"  wrote:



Just my two pence, but right now I understand these things are
possible with ViewDispatchPF and SnippetDispatchPF etc etc and all the
other tools we have in lift for creating modular view and logic code.

However, the one thing I would say is that a lot of people appear to
struggle with the particulars of how the hell one goes about creating
a plugin / module / component – this must mean we are not doing
something right... Even if it is just in communication of these things
to the community as a whole.

@dpp I know you mentioned you were going to make me a sample (re this
thread:
http://groups.google.com/group/liftweb/browse_thread/thread/932a730659975d0d
)

I know its a big ask, but any chance you could bash something out that
the community can consume and regurgitate some proper documentation /
tutorial on? (perhaps I could scala-blog it or similar)

Cheers, Tim

On Apr 2, 4:34 pm, David Pollak  wrote:
> On Thu, Apr 2, 2009 at 7:30 AM, Josh Suereth wrote:

> > > My resources are pretty limited, but I'd love to at least contribute
what I > > can to the OSG...

> > feeder.of.the.be...@gmail.com> wrote: > > >> Folks, > > >> I think we've
got our Lift 1.1 list. ...

> >> Lift, the simply functional web frameworkhttp://liftweb.net
> >> Beginning Scalahttp://www.apress.com/book/view/1430219890

> >> Follow me:http://twitter.com/dpp > >> Git some:http://github.com/dpp >
> --

> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890

> Follow me:http://twitter.com/dpp > Git 
> some:http://github.com/dpp--~--~-~--~~...

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

[Lift] Re: Forms & validation formatter

[Clemens Oertel]

One follow up question, relating to the contexts I mentioned earlier:  
Following my approach mentioned below, let's assume I have a template  
for embedding. This template contains  the HTML code for a tabular  
list of data entities. Depending on where the template is embedded,  
some of the entities' fields should appear as links: There are 2  
linkable reference fields A and B, and depending on the context,  
either A, B, or A and B should be rendered as links to the referenced  
entity.

This logic obviously can't go into the template. Also, the model's  
toForm method is unsuitable (having the model referring to a  
RequestVar seems evil to me). No no, this should go into the snippet,  
where such logic belongs. But this would mean having to go through the  
templates XML tree before calling Site.toForm(site, form), enclosing  
all affected liftf:field elements with the respective links. This  
sounds very, very wrong.

Thus, from my current understanding, this context-sensitive rendering  
of fields is best done using the explicit lift-tag/bind approach. So  
I'll probably have to have explicit bind calls anyways, and won't be  
able to use my initial approach of having the mapper class (or it's  
companion object) fill out the forms itself.

I'd be happy if someone could prove me wrong ...

Best,
Clemens

PS: Exercise for the reader: Instead of selective linking, have only  
either A or B be displayed, depending on the embedding context.

On 31-Mar-09, at 3:59 PM, marius d. wrote:

>>
>>  Outer Template 
>> 
>>Create a New Site
>>
>>
>>  
>>
>>  
>>Submit
>>  
>>
>>
>>  
>>
>> 
>>  End Outer Template 
>>
>>  Embedded Template 
>> 
>> 
>>  Name:> td>
>>  A Hospital Site
>>  
>> 
>> 
>>  End Embedded Template 
>>
>>  SiteOps 
>>def add(form: NodeSeq): NodeSeq = {
>>  val invokedAs = S.invokedAs
>>  val site = Site.create
>>
>>  def newSite(form: NodeSeq): NodeSeq = {
>>def saveMe(): Unit = {
>>  site.validate match {
>>case Nil => site.save ; S.notice("Added " + site.name);
>> S.redirectTo("/sites/")
>>case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
>>  }
>>}
>>
>>bind("site", Site.toForm(site, form), "submit" ->
>> submit("Save", saveMe))
>>  }
>>
>>  newSite(form)
>>}
>>  End SiteOps 
>>
>> The Site.toForm function is pretty much the same as found in
>> MetaRecord. It will eventually call each fields' toForm function
>> (which are the original Lift 1.0 mapper versions, no changes there).
>>
>> Am I really doing things outside the rendering pipeline (this is  
>> not a
>> rhetorical question)?
>
> Nope sorry ... I misunderstood your case. By bad entirely.
>
> It all seems to work, incl. validation.
>> Also, the eagerly evaluated template, which will be passed to toForm,
>> contains only field tags, no other lift tags.
>>
>> Again, imagine a few dozen different entities, each with a ton of
>> fields. I'm sure you'll understand that I'm hesitant to bind each
>> field manually (once for the list page, once for the display page,
>> once for the add page, and again once for the edit page, even though
>> the last 2 can surely be combined into one bind call in the code).
>> I obviously have to declare each field in the model, and refer to it
>> in the view. I really wouldn't mind not having to mention it anywhere
>> inbetween.
>
> This is actually a nice thing to do. Sorry that I misunderstood your
> intentions :)
>
>>
>> Thank you for all your help,
>> Clemens
>>
>> Clemens Oertel
>> clem...@oertel.ca
> >

Clemens Oertel
clem...@oertel.ca



Clemens Oertel
clem...@oertel.ca




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

[Lift] Re: Need for lightweight JPA archetype

[Timothy Perrett]

Are you eyeing up for your first commit Chas? ;-)

The src of the JPA archetype is here:

http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb41b640/lift-archetype-jpa-basic

Cheers, Tim

On Apr 2, 6:02 pm, "Charles F. Munat"  wrote:
> Where is the code for these archetypes and how tricky is it to create them?
>
> Chas.

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

[Lift] Re: The Lift 1.1 list

[Timothy Perrett]

Just my two pence, but right now I understand these things are
possible with ViewDispatchPF and SnippetDispatchPF etc etc and all the
other tools we have in lift for creating modular view and logic code.

However, the one thing I would say is that a lot of people appear to
struggle with the particulars of how the hell one goes about creating
a plugin / module / component – this must mean we are not doing
something right... Even if it is just in communication of these things
to the community as a whole.

@dpp I know you mentioned you were going to make me a sample (re this
thread:
http://groups.google.com/group/liftweb/browse_thread/thread/932a730659975d0d
)

I know its a big ask, but any chance you could bash something out that
the community can consume and regurgitate some proper documentation /
tutorial on? (perhaps I could scala-blog it or similar)

Cheers, Tim

On Apr 2, 4:34 pm, David Pollak  wrote:
> On Thu, Apr 2, 2009 at 7:30 AM, Josh Suereth wrote:
>
> > My resources are pretty limited, but I'd love to at least contribute what I
> > can to the OSGi support.  I'd love to see a plugin system for lift apps
> > that's sensible!
>
> Cool.  I'm hoping that Heiko will lead the efforts, but extra hands always
> help. :-)
>
>
>
> > Speaking of which, perhaps a plugin system that's sensible should be part
> > of the list?  I know grails does some neat stuff there with creating plugins
> > (but their packaging/distribution model was less than desirable IMHO).
> > Granted, a "plugin" in grails usually means "nice library" in scala, but
> > being able to define extension points and plug in features would be handy
> > (in certain circumstances.  Hudson is my example of a good use of these
> > features).
>
> I don't understand what a plugin is in the context of Lift.  There's not
> much you can't do simply by defining a DispatchPF or a page with SiteMap.
>
>
>
>
>
> > -Josh
>
> > On Wed, Apr 1, 2009 at 12:11 PM, David Pollak <
> > feeder.of.the.be...@gmail.com> wrote:
>
> >> Folks,
>
> >> I think we've got our Lift 1.1 list.  If anyone has anything to add,
> >> please speak up now.
>
> >>    - Improved documentation: better VScalaDoc coverage as well as better
> >>    tutorial and cook-book documentation.
> >>    - Improved J2EE support including JTA and Portlets.
> >>    - Finish Record/Field code with backing store including JDBC, JPA and
> >>    Goat Rodeo (what's Goat Rodeo?http://goatrodeo.org)
> >>    - Improved client-side JavaScript support and better JavaScript
> >>    abstractions.
> >>    - Client/Server data synchronization (integrated with Record/Field)
> >>    - Improved support for REST.
> >>    - Improved performance including caching templates when running in
> >>    production mode.
> >>    - OSGi support.
> >>    - Improved testing framework and better testing support when running
> >>    in "test" mode.
> >>    - Implement Servlet 3.0 support.
> >>    - HTML 5 and Web Sockets support and integration with Kaazing's Web
> >>    Sockets server.  Also, sensing which browser is making the request and
> >>    performing optimizations based on that browser's characteristics
> >>    (specifically, Chrome and Firefox 3.1 support)
>
> >> We will have bug-fix releases of 1.0 along the way and we'll have a
> >> release off the 1.0 branch when Scala 2.8 is released.
>
> >> Feedback is welcome in the next 3 days.
>
> >> Thanks,
>
> >> David
>
> >> --
> >> Lift, the simply functional web frameworkhttp://liftweb.net
> >> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >> Follow me:http://twitter.com/dpp
> >> Git some:http://github.com/dpp
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Need for lightweight JPA archetype

[Charles F. Munat]

Hmm. I forgot about EARs. Thanks for this information. I'll play around 
with it over the weekend.

Chas.

Derek Chen-Becker wrote:
> I don't know if this is typical, but I typically deploy my apps in an 
> EAR, in which case you just add another "EAR Build" module that packages 
> up the Persistence module as an EJB module (v3) and then adds the 
> WAR(s). It requires that you make some slight changes to the POM for the 
> Persistence module (change packaging to ejb), but otherwise it's a 
> simple change. Otherwise, you can just deploy the JPA module jar and 
> webapp modules separately. To answer your question, I think that you 
> should be able to just duplicate the existing project, although I think 
> that you should be able to handle enforcing login and SSL via SiteMap 
> for just the portions you want to protect.
> 
> Derek
> 
> On Thu, Apr 2, 2009 at 12:41 AM, Charles F. Munat  > wrote:
> 
> 
> Hmmm. This brings up something I've been meaning to ask about.
> 
> I have a public JPA app which has a log-in only maintenance area. I'm
> thinking about moving the maintenance part to a subdomain and serving it
> via SSL.
> 
> I think it would be easier to pull out a separate sub-project, so I
> might have the persistance sub-project, the public sub-project, and the
> admin-subproject.
> 
> Is this a good idea? And is it just as easy as copying the current
> webapp subproject, renaming it, and then deleting the parts that don't
> belong in each of the public and admin sub-projects?
> 
> But then how would I package it? How would I deploy it?
> 
> Has anyone done anything like this?
> 
> Chas.
> 
> Timothy Perrett wrote:
>  > I 100% see why you want a seperate module for persistance, but
>  > workflow wise I've found JPA a lot more productive if it's in the
> lift
>  > app as it means you don't have to keep deploying the JAR into your
>  > local repo.
>  >
>  > Perhaps
>  >
>  >  lift-jpa-archetype-blank-split
>  >  lift-jpa-archetype-blank-consolidated
>  >
>  >
>  > Thoughts?
>  >
>  > Tim
>  >
>  >
>  > On Apr 2, 7:33 am, Derek Chen-Becker  > wrote:
>  >> I thought I had sent out an email on the list earlier asking
> what people
>  >> would want to see in such an archetype. As a base, probably a
> master POM
>  >> with a module for the persistence unit and a module for the Lift
> side of
>  >> things. The persistence unit could have a skeleton
> persistence.xml in the
>  >> right place but otherwise be empty. The Lift side could have the
> basic Boot
>  >> and perhaps a Model class set up with a placeholder persistence
> setup.
>  >> Thoughts?
>  >>
>  >> Derek
>  >>
>  >> On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett
> wrote:
>  >>
>  >>
>  >>
>  >>> Glad im not the only one ;-)
>  >>> On Apr 1, 11:15 pm, Viktor Klang  > wrote:
>   Timmy,
>   yeah, I can see that coming in handy.
>   Cheers,
>   Viktor
>   On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett
>    wrote:
>  > Guys,
>  > Do people see room for a blank JPA archetype just like we
> have blank
>  > and basic of normal lift archetypes?
>  > IMO, whilst its great having the basic one for learning and
> examples,
>  > having something thats a workable starting point without
> having to
>  > remove code etc would be helpful.
>  > I appreciate this is a bit lazy - but i don't think it would
> take much
>  > work and would provide a neat solution
>  > Thoughts?
>  > Tim
>   --
>   Viktor Klang
>   Senior Systems Analyst
>  > >
> 
> 
> 
> 
> > 

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

[Lift] Re: Need for lightweight JPA archetype

[Charles F. Munat]

Where is the code for these archetypes and how tricky is it to create them?

Chas.

Timothy Perrett wrote:
> I guess if your deploying into an "enterprise container", then EAR is
> fine, however if your deploying into Jetty then you don't have the
> possibility of deploying to EAR. I just think that having the
> possibility of creating either a merged project or a split project is
> important as JPA brings things to the table some great features that
> people should be able to use however they want.
> 
> IMO, the archetypes are enablers - I know we could create this stuff
> manually, but we want to enable people to be productive quickly.
> 
> Thoughts?
> 
> Tim
> 
> On Apr 2, 3:06 pm, Derek Chen-Becker  wrote:
>> Works for me :)
>>
>> On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett 
>> wrote:
>>
>>
>>
>>> I 100% see why you want a seperate module for persistance, but
>>> workflow wise I've found JPA a lot more productive if it's in the lift
>>> app as it means you don't have to keep deploying the JAR into your
>>> local repo.
>>> Perhaps
>>>  lift-jpa-archetype-blank-split
>>>  lift-jpa-archetype-blank-consolidated
>>> Thoughts?
>>> Tim
>>> On Apr 2, 7:33 am, Derek Chen-Becker  wrote:
 I thought I had sent out an email on the list earlier asking what people
 would want to see in such an archetype. As a base, probably a master POM
 with a module for the persistence unit and a module for the Lift side of
 things. The persistence unit could have a skeleton persistence.xml in the
 right place but otherwise be empty. The Lift side could have the basic
>>> Boot
 and perhaps a Model class set up with a placeholder persistence setup.
 Thoughts?
 Derek
 On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett >>> wrote:
> Glad im not the only one ;-)
> On Apr 1, 11:15 pm, Viktor Klang  wrote:
>> Timmy,
>> yeah, I can see that coming in handy.
>> Cheers,
>> Viktor
>> On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett > wrote:
>>> Guys,
>>> Do people see room for a blank JPA archetype just like we have
>>> blank
>>> and basic of normal lift archetypes?
>>> IMO, whilst its great having the basic one for learning and
>>> examples,
>>> having something thats a workable starting point without having to
>>> remove code etc would be helpful.
>>> I appreciate this is a bit lazy - but i don't think it would take
>>> much
>>> work and would provide a neat solution
>>> Thoughts?
>>> Tim
>> --
>> Viktor Klang
>> Senior Systems Analyst
> > 

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

[Lift] Re: Menu widget bugginess

[Charles F. Munat]

Hmmm. Your google-fu is very powerful! "The fix is so simpel"!

I think this will probably work in this instance, but I'm pretty sure it 
doesn't work in every case, e.g. form inputs... else why the bother of 
using iframes via bgiframe.js? But for the Widgets examples, it looks 
like plain old divs, so I'll check it out when I get a break.

Thanks!

Chas.

Viktor Klang wrote:
> Hello Chas,
> 
> Can it be related to this: 
> http://webdemar.com/webdesign/superfish-jquery-menu-ie-z-index-bug/
> 
> Cheers,
> Viktor
> 
> On Thu, Apr 2, 2009 at 3:40 AM, Charles F. Munat  > wrote:
> 
> 
> I'm running the Lift Menu widget on my Mac via mvn jetty:run, then
> looking at it in IE Tester running in Windows XP Pro in a VMWare virtual
> machine on a Fedora 9 box on the same network. (Whew.)
> 
> In IE 8 it works fine.
> 
> In IE 7 and IE 6, on the CalendarWeekView and CalendarDayView pages, the
> third submenu link slides under the week or day view of the calendar and
> becomes inaccessible (and invisible as well). This is a typical problem
> with these piece of shit browsers that every self-respecting human on
> this planet should have rejected long ago... whoops. Did I write that
> out loud?
> 
> The fix involves bigiframe.js, which I see is included in the toserve
> directory and on the page, so I'm not really sure why this problem is
> occurring. Isn't that what bigiframe.js is supposed to solve?
> 
> Chas.
> 
> 
> 
> 
> 
> 
> -- 
> Viktor Klang
> Senior Systems Analyst
> 
> > 

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

[Lift] Re: Widget CSS

[Charles F. Munat]

Well, maybe I'm missing something, but when I turn on the TableSorter, 
the header cells of my table change color to the colors specified in the 
TableSorter CSS. That's because the colors I set in my default CSS file 
came earlier in the cascade.

It's not a big deal for me, but I thought I'd mention it. I don't have 
time to play with it today, but maybe tomorrow I can try using styles 
per id. That will probably work. I'll let you know.

Chas.

marius d. wrote:
> Can you "scope" your stylesheet props? ... such as adding prefixes to
> classes etc. ... or use styles per ID-s.
> 
> Looks to me that even if we change the order the application specific
> styles could potentially conflict with TableSorter's. The
> TableSorter's CSS are coming from JQuery plugin and not really
> proprietary so we probably should not change that.
> 
> Do you have an example of the conflict?
> 
> Br's,
> Marius
> 
> On Apr 2, 7:47 am, "Charles F. Munat"  wrote:
>> I've been playing with the very cool TableSorter widget. Nice work.
>>
>> One hassle though -- it inserts its stylesheet *after* my stylesheet, so
>> it overrides my styles. I could change things locally, but that's a
>> hassle. Might be able to add "important" qualifiers or some trick like
>> that, but it would be easiest if I could just turn that stylesheet off
>> and use my own.
>>
>> Any luck on that, or do I have to reinvent the TableSorter?
>>
>> Chas.
> > 

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

[Lift] Re: Need for lightweight JPA archetype

[Timothy Perrett]

I guess if your deploying into an "enterprise container", then EAR is
fine, however if your deploying into Jetty then you don't have the
possibility of deploying to EAR. I just think that having the
possibility of creating either a merged project or a split project is
important as JPA brings things to the table some great features that
people should be able to use however they want.

IMO, the archetypes are enablers - I know we could create this stuff
manually, but we want to enable people to be productive quickly.

Thoughts?

Tim

On Apr 2, 3:06 pm, Derek Chen-Becker  wrote:
> Works for me :)
>
> On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett 
> wrote:
>
>
>
> > I 100% see why you want a seperate module for persistance, but
> > workflow wise I've found JPA a lot more productive if it's in the lift
> > app as it means you don't have to keep deploying the JAR into your
> > local repo.
>
> > Perhaps
>
> >  lift-jpa-archetype-blank-split
> >  lift-jpa-archetype-blank-consolidated
>
> > Thoughts?
>
> > Tim
>
> > On Apr 2, 7:33 am, Derek Chen-Becker  wrote:
> > > I thought I had sent out an email on the list earlier asking what people
> > > would want to see in such an archetype. As a base, probably a master POM
> > > with a module for the persistence unit and a module for the Lift side of
> > > things. The persistence unit could have a skeleton persistence.xml in the
> > > right place but otherwise be empty. The Lift side could have the basic
> > Boot
> > > and perhaps a Model class set up with a placeholder persistence setup.
> > > Thoughts?
>
> > > Derek
>
> > > On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett  > >wrote:
>
> > > > Glad im not the only one ;-)
>
> > > > On Apr 1, 11:15 pm, Viktor Klang  wrote:
> > > > > Timmy,
>
> > > > > yeah, I can see that coming in handy.
>
> > > > > Cheers,
> > > > > Viktor
>
> > > > > On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett  > > > >wrote:
>
> > > > > > Guys,
>
> > > > > > Do people see room for a blank JPA archetype just like we have
> > blank
> > > > > > and basic of normal lift archetypes?
>
> > > > > > IMO, whilst its great having the basic one for learning and
> > examples,
> > > > > > having something thats a workable starting point without having to
> > > > > > remove code etc would be helpful.
>
> > > > > > I appreciate this is a bit lazy - but i don't think it would take
> > much
> > > > > > work and would provide a neat solution
>
> > > > > > Thoughts?
>
> > > > > > Tim
>
> > > > > --
> > > > > Viktor Klang
> > > > > Senior Systems Analyst
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: The Lift 1.1 list

[David Pollak]

On Thu, Apr 2, 2009 at 7:30 AM, Josh Suereth wrote:

> My resources are pretty limited, but I'd love to at least contribute what I
> can to the OSGi support.  I'd love to see a plugin system for lift apps
> that's sensible!


Cool.  I'm hoping that Heiko will lead the efforts, but extra hands always
help. :-)


>
>
> Speaking of which, perhaps a plugin system that's sensible should be part
> of the list?  I know grails does some neat stuff there with creating plugins
> (but their packaging/distribution model was less than desirable IMHO).
> Granted, a "plugin" in grails usually means "nice library" in scala, but
> being able to define extension points and plug in features would be handy
> (in certain circumstances.  Hudson is my example of a good use of these
> features).
>

I don't understand what a plugin is in the context of Lift.  There's not
much you can't do simply by defining a DispatchPF or a page with SiteMap.


>
> -Josh
>
>
> On Wed, Apr 1, 2009 at 12:11 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Folks,
>>
>> I think we've got our Lift 1.1 list.  If anyone has anything to add,
>> please speak up now.
>>
>>- Improved documentation: better VScalaDoc coverage as well as better
>>tutorial and cook-book documentation.
>>- Improved J2EE support including JTA and Portlets.
>>- Finish Record/Field code with backing store including JDBC, JPA and
>>Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org)
>>- Improved client-side JavaScript support and better JavaScript
>>abstractions.
>>- Client/Server data synchronization (integrated with Record/Field)
>>- Improved support for REST.
>>- Improved performance including caching templates when running in
>>production mode.
>>- OSGi support.
>>- Improved testing framework and better testing support when running
>>in "test" mode.
>>- Implement Servlet 3.0 support.
>>- HTML 5 and Web Sockets support and integration with Kaazing's Web
>>Sockets server.  Also, sensing which browser is making the request and
>>performing optimizations based on that browser's characteristics
>>(specifically, Chrome and Firefox 3.1 support)
>>
>> We will have bug-fix releases of 1.0 along the way and we'll have a
>> release off the 1.0 branch when Scala 2.8 is released.
>>
>> Feedback is welcome in the next 3 days.
>>
>> 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
>> Git some: http://github.com/dpp
>>
>>
>>
>
> >
>


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

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

[Lift] Re: The Lift 1.1 list

[Josh Suereth]

My resources are pretty limited, but I'd love to at least contribute what I
can to the OSGi support.  I'd love to see a plugin system for lift apps
that's sensible!

Speaking of which, perhaps a plugin system that's sensible should be part of
the list?  I know grails does some neat stuff there with creating plugins
(but their packaging/distribution model was less than desirable IMHO).
Granted, a "plugin" in grails usually means "nice library" in scala, but
being able to define extension points and plug in features would be handy
(in certain circumstances.  Hudson is my example of a good use of these
features).

-Josh

On Wed, Apr 1, 2009 at 12:11 PM, David Pollak  wrote:

> Folks,
>
> I think we've got our Lift 1.1 list.  If anyone has anything to add, please
> speak up now.
>
>- Improved documentation: better VScalaDoc coverage as well as better
>tutorial and cook-book documentation.
>- Improved J2EE support including JTA and Portlets.
>- Finish Record/Field code with backing store including JDBC, JPA and
>Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org)
>- Improved client-side JavaScript support and better JavaScript
>abstractions.
>- Client/Server data synchronization (integrated with Record/Field)
>- Improved support for REST.
>- Improved performance including caching templates when running in
>production mode.
>- OSGi support.
>- Improved testing framework and better testing support when running in
>"test" mode.
>- Implement Servlet 3.0 support.
>- HTML 5 and Web Sockets support and integration with Kaazing's Web
>Sockets server.  Also, sensing which browser is making the request and
>performing optimizations based on that browser's characteristics
>(specifically, Chrome and Firefox 3.1 support)
>
> We will have bug-fix releases of 1.0 along the way and we'll have a release
> off the 1.0 branch when Scala 2.8 is released.
>
> Feedback is welcome in the next 3 days.
>
> 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
> Git some: http://github.com/dpp
>
> >
>

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

[Lift] Re: Menu widget bugginess

[Viktor Klang]

Hello Chas,

Can it be related to this:
http://webdemar.com/webdesign/superfish-jquery-menu-ie-z-index-bug/

Cheers,
Viktor

On Thu, Apr 2, 2009 at 3:40 AM, Charles F. Munat  wrote:

>
> I'm running the Lift Menu widget on my Mac via mvn jetty:run, then
> looking at it in IE Tester running in Windows XP Pro in a VMWare virtual
> machine on a Fedora 9 box on the same network. (Whew.)
>
> In IE 8 it works fine.
>
> In IE 7 and IE 6, on the CalendarWeekView and CalendarDayView pages, the
> third submenu link slides under the week or day view of the calendar and
> becomes inaccessible (and invisible as well). This is a typical problem
> with these piece of shit browsers that every self-respecting human on
> this planet should have rejected long ago... whoops. Did I write that
> out loud?
>
> The fix involves bigiframe.js, which I see is included in the toserve
> directory and on the page, so I'm not really sure why this problem is
> occurring. Isn't that what bigiframe.js is supposed to solve?
>
> Chas.
>
>
> >
>


-- 
Viktor Klang
Senior Systems Analyst

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

[Lift] Re: The Lift 1.1 list

[David Pollak]

On Thu, Apr 2, 2009 at 2:30 AM, Bill Venners  wrote:

>
> Hi David,
>
> On Thu, Apr 2, 2009 at 12:11 AM, David Pollak
>  wrote:
> > Folks,
> >
> > Improved testing framework and better testing support when running in
> "test"
> > mode.
> >
> Can you elaborate on what your plans are for this?


It's a goal, not a set of plans.  I'm expecting one of the committers would
take ownership and figure it out.  Wanna be a committer, take ownership, and
figure it out?


>
>
> Thanks.
>
> Bill
>
> >
>


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

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

[Lift] Re: The Lift 1.1 list

[Bill Venners]

Hi David,

On Thu, Apr 2, 2009 at 12:11 AM, David Pollak
 wrote:
> Folks,
>
> Improved testing framework and better testing support when running in "test"
> mode.
>
Can you elaborate on what your plans are for this?

Thanks.

Bill

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

[Lift] Re: Widget CSS

[marius d.]

Can you "scope" your stylesheet props? ... such as adding prefixes to
classes etc. ... or use styles per ID-s.

Looks to me that even if we change the order the application specific
styles could potentially conflict with TableSorter's. The
TableSorter's CSS are coming from JQuery plugin and not really
proprietary so we probably should not change that.

Do you have an example of the conflict?

Br's,
Marius

On Apr 2, 7:47 am, "Charles F. Munat"  wrote:
> I've been playing with the very cool TableSorter widget. Nice work.
>
> One hassle though -- it inserts its stylesheet *after* my stylesheet, so
> it overrides my styles. I could change things locally, but that's a
> hassle. Might be able to add "important" qualifiers or some trick like
> that, but it would be easiest if I could just turn that stylesheet off
> and use my own.
>
> Any luck on that, or do I have to reinvent the TableSorter?
>
> Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Need for lightweight JPA archetype

[Derek Chen-Becker]

Works for me :)

On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett wrote:

>
> I 100% see why you want a seperate module for persistance, but
> workflow wise I've found JPA a lot more productive if it's in the lift
> app as it means you don't have to keep deploying the JAR into your
> local repo.
>
> Perhaps
>
>  lift-jpa-archetype-blank-split
>  lift-jpa-archetype-blank-consolidated
>
>
> Thoughts?
>
> Tim
>
>
> On Apr 2, 7:33 am, Derek Chen-Becker  wrote:
> > I thought I had sent out an email on the list earlier asking what people
> > would want to see in such an archetype. As a base, probably a master POM
> > with a module for the persistence unit and a module for the Lift side of
> > things. The persistence unit could have a skeleton persistence.xml in the
> > right place but otherwise be empty. The Lift side could have the basic
> Boot
> > and perhaps a Model class set up with a placeholder persistence setup.
> > Thoughts?
> >
> > Derek
> >
> > On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett  >wrote:
> >
> >
> >
> > > Glad im not the only one ;-)
> >
> > > On Apr 1, 11:15 pm, Viktor Klang  wrote:
> > > > Timmy,
> >
> > > > yeah, I can see that coming in handy.
> >
> > > > Cheers,
> > > > Viktor
> >
> > > > On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett  > > >wrote:
> >
> > > > > Guys,
> >
> > > > > Do people see room for a blank JPA archetype just like we have
> blank
> > > > > and basic of normal lift archetypes?
> >
> > > > > IMO, whilst its great having the basic one for learning and
> examples,
> > > > > having something thats a workable starting point without having to
> > > > > remove code etc would be helpful.
> >
> > > > > I appreciate this is a bit lazy - but i don't think it would take
> much
> > > > > work and would provide a neat solution
> >
> > > > > Thoughts?
> >
> > > > > Tim
> >
> > > > --
> > > > Viktor Klang
> > > > Senior Systems Analyst
> >
>

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

[Lift] Re: Need for lightweight JPA archetype

[Derek Chen-Becker]

I don't know if this is typical, but I typically deploy my apps in an EAR,
in which case you just add another "EAR Build" module that packages up the
Persistence module as an EJB module (v3) and then adds the WAR(s). It
requires that you make some slight changes to the POM for the Persistence
module (change packaging to ejb), but otherwise it's a simple change.
Otherwise, you can just deploy the JPA module jar and webapp modules
separately. To answer your question, I think that you should be able to just
duplicate the existing project, although I think that you should be able to
handle enforcing login and SSL via SiteMap for just the portions you want to
protect.

Derek

On Thu, Apr 2, 2009 at 12:41 AM, Charles F. Munat  wrote:

>
> Hmmm. This brings up something I've been meaning to ask about.
>
> I have a public JPA app which has a log-in only maintenance area. I'm
> thinking about moving the maintenance part to a subdomain and serving it
> via SSL.
>
> I think it would be easier to pull out a separate sub-project, so I
> might have the persistance sub-project, the public sub-project, and the
> admin-subproject.
>
> Is this a good idea? And is it just as easy as copying the current
> webapp subproject, renaming it, and then deleting the parts that don't
> belong in each of the public and admin sub-projects?
>
> But then how would I package it? How would I deploy it?
>
> Has anyone done anything like this?
>
> Chas.
>
> Timothy Perrett wrote:
> > I 100% see why you want a seperate module for persistance, but
> > workflow wise I've found JPA a lot more productive if it's in the lift
> > app as it means you don't have to keep deploying the JAR into your
> > local repo.
> >
> > Perhaps
> >
> >  lift-jpa-archetype-blank-split
> >  lift-jpa-archetype-blank-consolidated
> >
> >
> > Thoughts?
> >
> > Tim
> >
> >
> > On Apr 2, 7:33 am, Derek Chen-Becker  wrote:
> >> I thought I had sent out an email on the list earlier asking what people
> >> would want to see in such an archetype. As a base, probably a master POM
> >> with a module for the persistence unit and a module for the Lift side of
> >> things. The persistence unit could have a skeleton persistence.xml in
> the
> >> right place but otherwise be empty. The Lift side could have the basic
> Boot
> >> and perhaps a Model class set up with a placeholder persistence setup.
> >> Thoughts?
> >>
> >> Derek
> >>
> >> On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett  >wrote:
> >>
> >>
> >>
> >>> Glad im not the only one ;-)
> >>> On Apr 1, 11:15 pm, Viktor Klang  wrote:
>  Timmy,
>  yeah, I can see that coming in handy.
>  Cheers,
>  Viktor
>  On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett   wrote:
> > Guys,
> > Do people see room for a blank JPA archetype just like we have blank
> > and basic of normal lift archetypes?
> > IMO, whilst its great having the basic one for learning and examples,
> > having something thats a workable starting point without having to
> > remove code etc would be helpful.
> > I appreciate this is a bit lazy - but i don't think it would take
> much
> > work and would provide a neat solution
> > Thoughts?
> > Tim
>  --
>  Viktor Klang
>  Senior Systems Analyst
> > >
>
> >
>

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

[Lift] Wiki example with specs and Mockito

[etorreborre]

Hi,

The Wiki example specification, which was previously specified using
JMock broke when we migrated to Scala 2.7.2 (compiler issue, couldn't
solve it).

However, the latest version of specs (1.4.4-SNAPSHOT) provides an
integration with Mockito which is even nicer when just doing stubbing.
So the Wiki Specification is now back on track and you can pull it
from git.

I want to note also one thing. The way the original example was
written wasn't very stub-friendly, so I had to change:

object WikiEntry extends WikiEntry with LongKeyedMetaMapper[WikiEntry]

to

object WikiEntry extends MetaWikiEntry // introduced the MetaWikiEntry
trait
trait MetaWikiEntry extends WikiEntry with LongKeyedMetaMapper
[WikiEntry]

and

class Wiki {
import WikiEntry._

to

// using the MetaWikiEntry trait to stub the database accesses
class Wiki extends MetaWikiEntry {

My hope is that Powermock (http://code.google.com/p/powermock) is
going to catchup with the latest version of Mockito and that we'll be
able to mock/stub any static method. In the meantime, I would advise
to avoid "static imports", like "import WikiEntry._" to facilitate
specifications/testing.

Cheers,

Eric.




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