[Lift] Record with the new bind-immutable

[Marius]

Oliver,

I very briefly looked on your code and I saw that you have your own
validator there. How would that play with the existent validattors
that Record has where each field has a list of :

type ValidationFunction = MyType => Box[Node]

Note that current MetaRecord's validator after evaluating the
validators for each field it yields a List[FieldError] which can be
easily naturally used with S.error function to show the error messages
etc.

Is there a redundancy or complementary functionality?

Br's,
Marius
--~--~-~--~~~---~--~~
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: git ouch

[Heiko Seeberger]

Hm, never looked at those images before. But I guess it is OK.
Heiko

2009/5/29 Oliver Lambert 

> I have a problem with breaking a build on my first attempt of working with
> git. I'm happy if I haven't, but what was concerning me was in the included
> image (the network line looks like wip-ol-immu is directly next to master,
> rather than on a separate branch - if this is normal, Im happy)
>
>
> On Fri, May 29, 2009 at 4:22 PM, Heiko Seeberger <
> heiko.seeber...@googlemail.com> wrote:
>
>> Oliver,
>> But that's perfect! What's your problem?
>>
>> There is one LOCAL wip-ol-immu branch and one REMOTE. That's how it is
>> expected to be for a branch you pushed.
>>
>> Heiko
>>
>> 2009/5/29 Oliver Lambert 
>>
>>  I got that list of commands wrong, what I typed, was
>>>
>>> git clone g...@github.com:dpp/liftweb.git
>>> git branch wip-ol-immu
>>> git checkout wip-ol-immu
>>> git push origin wip-ol-immu
>>>
>>> When I do a git branch -a, I get two wip-ol-immu
>>>   master
>>> * wip-ol-immu
>>>   origin/1.0_maint
>>>   origin/HEAD
>>>   origin/master
>>>   origin/new_actor
>>>   origin/wip-boolean-can
>>>   origin/wip-dcb-derby-binary
>>>   origin/wip-dcb-jpa-jta
>>>   origin/wip-dcb-jpa-validation
>>>   origin/wip-dcb-lift-jpa
>>>   origin/wip-dpp-record
>>>   origin/wip-marius-dom-optimizations
>>>   origin/wip-ol-immu
>>>   origin/wip-prettify
>>>   origin/wip-record2-dpp
>>>
>>>
>>>
>>>
>
> >
>


-- 
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: www.scalamodules.org
Lift, the simply functional web framework: liftweb.net

--~--~-~--~~~---~--~~
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: Record with the new bind-immutable

[Oliver Lambert]

I'm aware of S.error and my ValidationError uses it when I'm ready to show
errors. I've briefly looked at the ValidationFunction and the thing I might
stumble on is the errorType which I rely on.

I may be able to refactor the code to use List[FieldError] as I don't think
I rely on errorType at this point.

I'll have a go at modifying the Binder code.

cheers
Oliver

On Fri, May 29, 2009 at 5:05 PM, Marius  wrote:

>
> Oliver,
>
> I very briefly looked on your code and I saw that you have your own
> validator there. How would that play with the existent validattors
> that Record has where each field has a list of :
>
> type ValidationFunction = MyType => Box[Node]
>
> Note that current MetaRecord's validator after evaluating the
> validators for each field it yields a List[FieldError] which can be
> easily naturally used with S.error function to show the error messages
> etc.
>
> Is there a redundancy or complementary functionality?
>
> Br's,
> Marius
> >
>

--~--~-~--~~~---~--~~
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: Record with the new bind-immutable

[marius d.]

I see ... still the question remains. What are we going to do with two
validators? I'd like to understand the principles of your addition
(... I know I should have dig into the code but I don't have much time
now).

I'd like to understand as I said previously if we have redundant
validators or complementary functionality so that people to not get
confused.

I'm not trying at all to be negative or anything, just trying to
understand the value added.

Br's,
Marius

On May 29, 11:01 am, Oliver Lambert  wrote:
> I'm aware of S.error and my ValidationError uses it when I'm ready to show
> errors. I've briefly looked at the ValidationFunction and the thing I might
> stumble on is the errorType which I rely on.
>
> I may be able to refactor the code to use List[FieldError] as I don't think
> I rely on errorType at this point.
>
> I'll have a go at modifying the Binder code.
>
> cheers
> Oliver
>
> On Fri, May 29, 2009 at 5:05 PM, Marius  wrote:
>
> > Oliver,
>
> > I very briefly looked on your code and I saw that you have your own
> > validator there. How would that play with the existent validattors
> > that Record has where each field has a list of :
>
> > type ValidationFunction = MyType => Box[Node]
>
> > Note that current MetaRecord's validator after evaluating the
> > validators for each field it yields a List[FieldError] which can be
> > easily naturally used with S.error function to show the error messages
> > etc.
>
> > Is there a redundancy or complementary functionality?
>
> > Br's,
> > Marius
--~--~-~--~~~---~--~~
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: git ouch

[Timothy Perrett]

Oliver,

There are detailed instructions on the committer mailing list as to
how to create a remote branch for lift. For reference, I include them
here (originally from Mr Weir, so credit to him for being the git
master!):

**Creating a Remote Branch**
1. Create the remote branch
git push origin origin:refs/heads/new_feature_name

2. Make sure everything is up-to-date
git fetch origin

3. Then you can see that the branch is created.
git branch -r

* This should show ‘origin/new_feature_name’

4. Start tracking the new branch
git checkout --track -b new_feature_name origin/new_feature_name

*This means that when you do pulls that it will get the latest from
that branch as well.

5. Make sure everything is up-to-date
git pull

**Cleaning up Mistakes**
If you make a mistake you can always delete the remote branch:
git push origin :heads/new_feature_name

Hope that helps

Cheers, Tim

On May 29, 8:32 am, Heiko Seeberger 
wrote:
> Hm, never looked at those images before. But I guess it is OK.
> Heiko
>
> 2009/5/29 Oliver Lambert 
>
>
>
>
>
> > I have a problem with breaking a build on my first attempt of working with
> > git. I'm happy if I haven't, but what was concerning me was in the included
> > image (the network line looks like wip-ol-immu is directly next to master,
> > rather than on a separate branch - if this is normal, Im happy)
>
> > On Fri, May 29, 2009 at 4:22 PM, Heiko Seeberger <
> > heiko.seeber...@googlemail.com> wrote:
>
> >> Oliver,
> >> But that's perfect! What's your problem?
>
> >> There is one LOCAL wip-ol-immu branch and one REMOTE. That's how it is
> >> expected to be for a branch you pushed.
>
> >> Heiko
>
> >> 2009/5/29 Oliver Lambert 
>
> >>  I got that list of commands wrong, what I typed, was
>
> >>> git clone g...@github.com:dpp/liftweb.git
> >>> git branch wip-ol-immu
> >>> git checkout wip-ol-immu
> >>> git push origin wip-ol-immu
>
> >>> When I do a git branch -a, I get two wip-ol-immu
> >>>   master
> >>> * wip-ol-immu
> >>>   origin/1.0_maint
> >>>   origin/HEAD
> >>>   origin/master
> >>>   origin/new_actor
> >>>   origin/wip-boolean-can
> >>>   origin/wip-dcb-derby-binary
> >>>   origin/wip-dcb-jpa-jta
> >>>   origin/wip-dcb-jpa-validation
> >>>   origin/wip-dcb-lift-jpa
> >>>   origin/wip-dpp-record
> >>>   origin/wip-marius-dom-optimizations
> >>>   origin/wip-ol-immu
> >>>   origin/wip-prettify
> >>>   origin/wip-record2-dpp
>
> --
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala:www.scalamodules.org
> Lift, the simply functional web framework: liftweb.net
--~--~-~--~~~---~--~~
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] JTA

[Jonas Bonér]

Hi guys.

I have been talking with David Pollak the rest of the lift team about
adding JTA to Lift. I have implemented that for a product written in
Scala some time ago. Now some of that code is OSS at:
http://github.com/jboner/skalman/tree

We used using two different APIs.
1. Annotations (would require Lift to support proxied objects, e.g.
grab them from a factory):

@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }

2. Call-by-name:

withTxRequired {
  ... // do transational stuff
}

But I don't know what fits Lift and would like to know how you guys
would like to have JTA integrated.
At which level? Which APIs? Etc.

--
Jonas Bonér

twitter: @jboner
blog:    http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

--~--~-~--~~~---~--~~
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: JTA

[marius d.]

I think that would be really good. But I'd rather not use annotations.
Personally I find closures approach a much better fit here.

withTxRequired {
  ... // do transational stuff

}


Br's,
Marius

On May 29, 11:55 am, Jonas Bonér  wrote:
> Hi guys.
>
> I have been talking with David Pollak the rest of the lift team about
> adding JTA to Lift. I have implemented that for a product written in
> Scala some time ago. Now some of that code is OSS 
> at:http://github.com/jboner/skalman/tree
>
> We used using two different APIs.
> 1. Annotations (would require Lift to support proxied objects, e.g.
> grab them from a factory):
>
> @TransactionAttribute(REQUIRED)
> def transactionalMethod = { ... }
>
> 2. Call-by-name:
>
> withTxRequired {
>   ... // do transational stuff
>
> }
>
> But I don't know what fits Lift and would like to know how you guys
> would like to have JTA integrated.
> At which level? Which APIs? Etc.
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog:    http://jonasboner.com
> work:  http://crisp.se
> work:  http://scalablesolutions.se
> code:  http://github.com/jboner
--~--~-~--~~~---~--~~
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: JTA

[Timothy Perrett]

Are there any performance implications considering closures vs annotations?
Agreed that closures are more "lift like" however.

Cheers, Tim

On 29/05/2009 10:21, "marius d."  wrote:

> 
> I think that would be really good. But I'd rather not use annotations.
> Personally I find closures approach a much better fit here.
> 
> withTxRequired {
>   ... // do transational stuff
> 
> }
> 
> 
> Br's,
> Marius
> 
> On May 29, 11:55 am, Jonas Bonér  wrote:
>> Hi guys.
>> 
>> I have been talking with David Pollak the rest of the lift team about
>> adding JTA to Lift. I have implemented that for a product written in
>> Scala some time ago. Now some of that code is OSS
>> at:http://github.com/jboner/skalman/tree
>> 
>> We used using two different APIs.
>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> grab them from a factory):
>> 
>> @TransactionAttribute(REQUIRED)
>> def transactionalMethod = { ... }
>> 
>> 2. Call-by-name:
>> 
>> withTxRequired {
>>   ... // do transational stuff
>> 
>> }
>> 
>> But I don't know what fits Lift and would like to know how you guys
>> would like to have JTA integrated.
>> At which level? Which APIs? Etc.
>> 
>> --
>> Jonas Bonér
>> 
>> twitter: @jboner
>> blog:    http://jonasboner.com
>> work:  http://crisp.se
>> work:  http://scalablesolutions.se
>> code:  http://github.com/jboner
> > 
> 



--~--~-~--~~~---~--~~
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: git ouch

[Oliver Lambert]

Thanks for this, wish I'd read it earlier.As a matter of interest, is there
anything else on the committer mailing list that a new committer
should read - and can I read emails posted before I became one?

cheers
Oliver
On Fri, May 29, 2009 at 6:39 PM, Timothy Perrett wrote:

>
> Oliver,
>
> There are detailed instructions on the committer mailing list as to
> how to create a remote branch for lift. For reference, I include them
> here (originally from Mr Weir, so credit to him for being the git
> master!):
>
> **Creating a Remote Branch**
> 1. Create the remote branch
> git push origin origin:refs/heads/new_feature_name
>
> 2. Make sure everything is up-to-date
> git fetch origin
>
> 3. Then you can see that the branch is created.
> git branch -r
>
> * This should show ‘origin/new_feature_name’
>
> 4. Start tracking the new branch
> git checkout --track -b new_feature_name origin/new_feature_name
>
> *This means that when you do pulls that it will get the latest from
> that branch as well.
>
> 5. Make sure everything is up-to-date
> git pull
>
> **Cleaning up Mistakes**
> If you make a mistake you can always delete the remote branch:
> git push origin :heads/new_feature_name
>
> Hope that helps
>
> Cheers, Tim
>
> On May 29, 8:32 am, Heiko Seeberger 
> wrote:
> > Hm, never looked at those images before. But I guess it is OK.
> > Heiko
> >
> > 2009/5/29 Oliver Lambert 
> >
> >
> >
> >
> >
> > > I have a problem with breaking a build on my first attempt of working
> with
> > > git. I'm happy if I haven't, but what was concerning me was in the
> included
> > > image (the network line looks like wip-ol-immu is directly next to
> master,
> > > rather than on a separate branch - if this is normal, Im happy)
> >
> > > On Fri, May 29, 2009 at 4:22 PM, Heiko Seeberger <
> > > heiko.seeber...@googlemail.com> wrote:
> >
> > >> Oliver,
> > >> But that's perfect! What's your problem?
> >
> > >> There is one LOCAL wip-ol-immu branch and one REMOTE. That's how it is
> > >> expected to be for a branch you pushed.
> >
> > >> Heiko
> >
> > >> 2009/5/29 Oliver Lambert 
> >
> > >>  I got that list of commands wrong, what I typed, was
> >
> > >>> git clone g...@github.com:dpp/liftweb.git
> > >>> git branch wip-ol-immu
> > >>> git checkout wip-ol-immu
> > >>> git push origin wip-ol-immu
> >
> > >>> When I do a git branch -a, I get two wip-ol-immu
> > >>>   master
> > >>> * wip-ol-immu
> > >>>   origin/1.0_maint
> > >>>   origin/HEAD
> > >>>   origin/master
> > >>>   origin/new_actor
> > >>>   origin/wip-boolean-can
> > >>>   origin/wip-dcb-derby-binary
> > >>>   origin/wip-dcb-jpa-jta
> > >>>   origin/wip-dcb-jpa-validation
> > >>>   origin/wip-dcb-lift-jpa
> > >>>   origin/wip-dpp-record
> > >>>   origin/wip-marius-dom-optimizations
> > >>>   origin/wip-ol-immu
> > >>>   origin/wip-prettify
> > >>>   origin/wip-record2-dpp
> >
> > --
> > My blog: heikoseeberger.name
> > Follow me: twitter.com/hseeberger
> > OSGi on Scala:www.scalamodules.org
> > Lift, the simply functional web framework: liftweb.net
> >
>

--~--~-~--~~~---~--~~
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: git ouch

[Timothy Perrett]

We use the committer list to discuss process orientated things like
when we are going to do a release, issue management, who's working on
what tasks etc etc. Its a private - committer only group that is not
publicly viewable.

I'll touch base with you off list :-)

Cheers, Tim

On May 29, 12:35 pm, Oliver Lambert  wrote:
> Thanks for this, wish I'd read it earlier.As a matter of interest, is there
> anything else on the committer mailing list that a new committer
> should read - and can I read emails posted before I became one?
>
> cheers
> Oliver
> On Fri, May 29, 2009 at 6:39 PM, Timothy Perrett 
> wrote:

--~--~-~--~~~---~--~~
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: How to disable jQuery from lift application?

[Narayanaswamy, Mohan]

I will try to send one, But Google API was failing while trying to load banner. 
Google just released those api's.

Mohan 

-Original Message-
From: liftweb@googlegroups.com [mailto:lift...@googlegroups.com] On Behalf Of 
Narayanaswamy, Mohan
Sent: 28 May 2009 00:32
To: Lift
Subject: [Lift] Re: How to disable jQuery from lift application?


As per my limited knowledge, Google javascript API fails. Below API, I am using 
it to transfer "English to Tamil" tranliteration.

Webpage error details

Message: Unexpected call to method or property access.
Line: 22
Char: 388
Code: 0
URI: 
http://www.google.com/uds/api/elements/1.0/1aac8bdeb1f85e7c5035029a61994691/transliteration.I.js


Mohan

On May 27, 8:21 pm, David Pollak 
wrote:
> Mohan,
>
> Marius answered your question, but I'm curious... how does jQuery 
> conflict with the google library?  What kind of errors are you seeing?
>
> Thanks,
>
> David
>
> On Tue, May 26, 2009 at 5:50 PM, KaniniPazham <
>
>
>
>
>
> mohan.narayanasw...@credit-suisse.com> wrote:
>
> > I am using  "Archetype basic" and in my form, I am trying to 
> > integrate with Google Transliteration API. So in one of the page, I 
> > would like to disable jQuery as it conflicts with google Transliteration 
> > API.
>
> > I found following function is generated and added automatically, 
> > they are not in my template.
>
> >  //  > jQuery(document).ready(function() {lift_successRegisterGC();}); var 
> > lift_page = 'F27052369736502T'; // ]]> 
>
> > How could I disable generating such a automatic jQuery script?
> > How could I disable jQuery for whole LiftApplication?
> > How could I disable jQuery for only one page?
>
> > Extremely sorry if the above questions are simple and stupid. Except 
> > Core-java, everything is new to me.
>
> > Mohan
>
> --
> 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- Hide quoted text -
>
> - Show quoted text -




==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


--~--~-~--~~~---~--~~
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: git ouch

[David Pollak]

On Fri, May 29, 2009 at 4:35 AM, Oliver Lambert  wrote:

> Thanks for this, wish I'd read it earlier.As a matter of interest, is
> there anything else on the committer mailing list that a new committer
> should read - and can I read emails posted before I became one?
>

Oliver,

If it makes you feel any better, I don't remember Tyler's excellent post
about how to create git branches.  I muddle through the branching process
each time I create a new one.

I'll have the afore mentioned instructions tattooed on my arm.

Thanks,

David


>
> cheers
> Oliver
>
> On Fri, May 29, 2009 at 6:39 PM, Timothy Perrett 
> wrote:
>
>>
>> Oliver,
>>
>> There are detailed instructions on the committer mailing list as to
>> how to create a remote branch for lift. For reference, I include them
>> here (originally from Mr Weir, so credit to him for being the git
>> master!):
>>
>> **Creating a Remote Branch**
>> 1. Create the remote branch
>> git push origin origin:refs/heads/new_feature_name
>>
>> 2. Make sure everything is up-to-date
>> git fetch origin
>>
>> 3. Then you can see that the branch is created.
>> git branch -r
>>
>> * This should show ‘origin/new_feature_name’
>>
>> 4. Start tracking the new branch
>> git checkout --track -b new_feature_name origin/new_feature_name
>>
>> *This means that when you do pulls that it will get the latest from
>> that branch as well.
>>
>> 5. Make sure everything is up-to-date
>> git pull
>>
>> **Cleaning up Mistakes**
>> If you make a mistake you can always delete the remote branch:
>> git push origin :heads/new_feature_name
>>
>> Hope that helps
>>
>> Cheers, Tim
>>
>> On May 29, 8:32 am, Heiko Seeberger 
>> wrote:
>> > Hm, never looked at those images before. But I guess it is OK.
>> > Heiko
>> >
>> > 2009/5/29 Oliver Lambert 
>> >
>> >
>> >
>> >
>> >
>> > > I have a problem with breaking a build on my first attempt of working
>> with
>> > > git. I'm happy if I haven't, but what was concerning me was in the
>> included
>> > > image (the network line looks like wip-ol-immu is directly next to
>> master,
>> > > rather than on a separate branch - if this is normal, Im happy)
>> >
>> > > On Fri, May 29, 2009 at 4:22 PM, Heiko Seeberger <
>> > > heiko.seeber...@googlemail.com> wrote:
>> >
>> > >> Oliver,
>> > >> But that's perfect! What's your problem?
>> >
>> > >> There is one LOCAL wip-ol-immu branch and one REMOTE. That's how it
>> is
>> > >> expected to be for a branch you pushed.
>> >
>> > >> Heiko
>> >
>> > >> 2009/5/29 Oliver Lambert 
>> >
>> > >>  I got that list of commands wrong, what I typed, was
>> >
>> > >>> git clone g...@github.com:dpp/liftweb.git
>> > >>> git branch wip-ol-immu
>> > >>> git checkout wip-ol-immu
>> > >>> git push origin wip-ol-immu
>> >
>> > >>> When I do a git branch -a, I get two wip-ol-immu
>> > >>>   master
>> > >>> * wip-ol-immu
>> > >>>   origin/1.0_maint
>> > >>>   origin/HEAD
>> > >>>   origin/master
>> > >>>   origin/new_actor
>> > >>>   origin/wip-boolean-can
>> > >>>   origin/wip-dcb-derby-binary
>> > >>>   origin/wip-dcb-jpa-jta
>> > >>>   origin/wip-dcb-jpa-validation
>> > >>>   origin/wip-dcb-lift-jpa
>> > >>>   origin/wip-dpp-record
>> > >>>   origin/wip-marius-dom-optimizations
>> > >>>   origin/wip-ol-immu
>> > >>>   origin/wip-prettify
>> > >>>   origin/wip-record2-dpp
>> >
>> > --
>> > My blog: heikoseeberger.name
>> > Follow me: twitter.com/hseeberger
>> > OSGi on Scala:www.scalamodules.org
>> > Lift, the simply functional web framework: liftweb.net
>>
>>
>
> >
>


-- 
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: Record with the new bind-immutable

[Oliver Lambert]

Hi Marius,
To try and answer your question, I had to go and look at the Record code in
more detail. I hadn't recently written the Binder Validator, so it wasn't
designed to be
complementary to anything else (however, some of the naming and methodology
is very
similar in both sets of code).

What I found.
1) MetaRecord.validate === Binder.validate
2) Field.validators === BoundObj.validations
3) Field.validationFunction === Validator.validate
4) List[FieldError]  === List[ValidationError]

Can I get rid of Binder Validation and just use Record/Field validation?
It certainly looks like I should try. However, I might have to add/change
some of the original Lift code.
For instance, I might want to add an errorType (with a default, so no code
is broken) to FieldError.
I might also want to move/change Field.validationFunction so its a little
more
like my Validator,with an errorType and toString (When I print my
validators, the errorType give a little
information on what they do, rather than just telling me I have a function -
I also filter using
the errorType)

Other things of interest that I found.

Could a Binder be a MetaRecord? There are definitely some similarities.
Binder holds a set of
immutable objects which can be an advantage, but MetaRecord can talk to
databases which is
kind of useful at times.

Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may
hold a reference to a string value
that is completely invalid. I'm not sure I see this in Field.

cheers
Oliver

On Fri, May 29, 2009 at 6:22 PM, marius d.  wrote:

>
> I see ... still the question remains. What are we going to do with two
> validators? I'd like to understand the principles of your addition
> (... I know I should have dig into the code but I don't have much time
> now).
>
> I'd like to understand as I said previously if we have redundant
> validators or complementary functionality so that people to not get
> confused.
>
> I'm not trying at all to be negative or anything, just trying to
> understand the value added.
>
> Br's,
> Marius
>
> On May 29, 11:01 am, Oliver Lambert  wrote:
> > I'm aware of S.error and my ValidationError uses it when I'm ready to
> show
> > errors. I've briefly looked at the ValidationFunction and the thing I
> might
> > stumble on is the errorType which I rely on.
> >
> > I may be able to refactor the code to use List[FieldError] as I don't
> think
> > I rely on errorType at this point.
> >
> > I'll have a go at modifying the Binder code.
> >
> > cheers
> > Oliver
> >
> > On Fri, May 29, 2009 at 5:05 PM, Marius  wrote:
> >
> > > Oliver,
> >
> > > I very briefly looked on your code and I saw that you have your own
> > > validator there. How would that play with the existent validattors
> > > that Record has where each field has a list of :
> >
> > > type ValidationFunction = MyType => Box[Node]
> >
> > > Note that current MetaRecord's validator after evaluating the
> > > validators for each field it yields a List[FieldError] which can be
> > > easily naturally used with S.error function to show the error messages
> > > etc.
> >
> > > Is there a redundancy or complementary functionality?
> >
> > > Br's,
> > > Marius
> >
>

--~--~-~--~~~---~--~~
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: Record with the new bind-immutable

[David Pollak]

One thing I've been thinking about is optionally extending the Validator
Functions to also emit JavaScript that would perform the validation in the
browser... that would provide a seamless way to do client-side validation
for validators (e.g., min len, max len, regex) that only rely on client-side
data.

On Fri, May 29, 2009 at 6:32 AM, Oliver Lambert  wrote:

> Hi Marius,
> To try and answer your question, I had to go and look at the Record code
> in
> more detail. I hadn't recently written the Binder Validator, so it wasn't
> designed to be
> complementary to anything else (however, some of the naming and methodology
> is very
> similar in both sets of code).
>
> What I found.
> 1) MetaRecord.validate === Binder.validate
> 2) Field.validators === BoundObj.validations
> 3) Field.validationFunction === Validator.validate
> 4) List[FieldError]  === List[ValidationError]
>
> Can I get rid of Binder Validation and just use Record/Field validation?
> It certainly looks like I should try. However, I might have to add/change
> some of the original Lift code.
> For instance, I might want to add an errorType (with a default, so no code
> is broken) to FieldError.
> I might also want to move/change Field.validationFunction so its a little
> more
> like my Validator,with an errorType and toString (When I print my
> validators, the errorType give a little
> information on what they do, rather than just telling me I have a function
> - I also filter using
> the errorType)
>
> Other things of interest that I found.
>
> Could a Binder be a MetaRecord? There are definitely some similarities.
> Binder holds a set of
> immutable objects which can be an advantage, but MetaRecord can talk to
> databases which is
> kind of useful at times.
>
> Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may
> hold a reference to a string value
> that is completely invalid. I'm not sure I see this in Field.
>
> cheers
> Oliver
>
> On Fri, May 29, 2009 at 6:22 PM, marius d. wrote:
>
>>
>> I see ... still the question remains. What are we going to do with two
>> validators? I'd like to understand the principles of your addition
>> (... I know I should have dig into the code but I don't have much time
>> now).
>>
>> I'd like to understand as I said previously if we have redundant
>> validators or complementary functionality so that people to not get
>> confused.
>>
>> I'm not trying at all to be negative or anything, just trying to
>> understand the value added.
>>
>> Br's,
>> Marius
>>
>> On May 29, 11:01 am, Oliver Lambert  wrote:
>> > I'm aware of S.error and my ValidationError uses it when I'm ready to
>> show
>> > errors. I've briefly looked at the ValidationFunction and the thing I
>> might
>> > stumble on is the errorType which I rely on.
>> >
>> > I may be able to refactor the code to use List[FieldError] as I don't
>> think
>> > I rely on errorType at this point.
>> >
>> > I'll have a go at modifying the Binder code.
>> >
>> > cheers
>> > Oliver
>> >
>> > On Fri, May 29, 2009 at 5:05 PM, Marius 
>> wrote:
>> >
>> > > Oliver,
>> >
>> > > I very briefly looked on your code and I saw that you have your own
>> > > validator there. How would that play with the existent validattors
>> > > that Record has where each field has a list of :
>> >
>> > > type ValidationFunction = MyType => Box[Node]
>> >
>> > > Note that current MetaRecord's validator after evaluating the
>> > > validators for each field it yields a List[FieldError] which can be
>> > > easily naturally used with S.error function to show the error messages
>> > > etc.
>> >
>> > > Is there a redundancy or complementary functionality?
>> >
>> > > Br's,
>> > > Marius
>>
>>
>
> >
>


-- 
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: Record with the new bind-immutable

[Oliver Lambert]

Oh, and I think I now have a better understanding of why David wanted me to
add this to the Record module.

On Fri, May 29, 2009 at 11:32 PM, Oliver Lambert wrote:

> Hi Marius,
> To try and answer your question, I had to go and look at the Record code
> in
> more detail. I hadn't recently written the Binder Validator, so it wasn't
> designed to be
> complementary to anything else (however, some of the naming and methodology
> is very
> similar in both sets of code).
>
> What I found.
> 1) MetaRecord.validate === Binder.validate
> 2) Field.validators === BoundObj.validations
> 3) Field.validationFunction === Validator.validate
> 4) List[FieldError]  === List[ValidationError]
>
> Can I get rid of Binder Validation and just use Record/Field validation?
> It certainly looks like I should try. However, I might have to add/change
> some of the original Lift code.
> For instance, I might want to add an errorType (with a default, so no code
> is broken) to FieldError.
> I might also want to move/change Field.validationFunction so its a little
> more
> like my Validator,with an errorType and toString (When I print my
> validators, the errorType give a little
> information on what they do, rather than just telling me I have a function
> - I also filter using
> the errorType)
>
> Other things of interest that I found.
>
> Could a Binder be a MetaRecord? There are definitely some similarities.
> Binder holds a set of
> immutable objects which can be an advantage, but MetaRecord can talk to
> databases which is
> kind of useful at times.
>
> Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may
> hold a reference to a string value
> that is completely invalid. I'm not sure I see this in Field.
>
> cheers
> Oliver
>
> On Fri, May 29, 2009 at 6:22 PM, marius d. wrote:
>
>>
>> I see ... still the question remains. What are we going to do with two
>> validators? I'd like to understand the principles of your addition
>> (... I know I should have dig into the code but I don't have much time
>> now).
>>
>> I'd like to understand as I said previously if we have redundant
>> validators or complementary functionality so that people to not get
>> confused.
>>
>> I'm not trying at all to be negative or anything, just trying to
>> understand the value added.
>>
>> Br's,
>> Marius
>>
>> On May 29, 11:01 am, Oliver Lambert  wrote:
>> > I'm aware of S.error and my ValidationError uses it when I'm ready to
>> show
>> > errors. I've briefly looked at the ValidationFunction and the thing I
>> might
>> > stumble on is the errorType which I rely on.
>> >
>> > I may be able to refactor the code to use List[FieldError] as I don't
>> think
>> > I rely on errorType at this point.
>> >
>> > I'll have a go at modifying the Binder code.
>> >
>> > cheers
>> > Oliver
>> >
>> > On Fri, May 29, 2009 at 5:05 PM, Marius 
>> wrote:
>> >
>> > > Oliver,
>> >
>> > > I very briefly looked on your code and I saw that you have your own
>> > > validator there. How would that play with the existent validattors
>> > > that Record has where each field has a list of :
>> >
>> > > type ValidationFunction = MyType => Box[Node]
>> >
>> > > Note that current MetaRecord's validator after evaluating the
>> > > validators for each field it yields a List[FieldError] which can be
>> > > easily naturally used with S.error function to show the error messages
>> > > etc.
>> >
>> > > Is there a redundancy or complementary functionality?
>> >
>> > > Br's,
>> > > Marius
>> >>
>>
>

--~--~-~--~~~---~--~~
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: JTA

[Jonas Bonér]

No perf difference. The annotations are turned into the same exact closures.

2009/5/29 Timothy Perrett :
>
>
> Are there any performance implications considering closures vs annotations?
> Agreed that closures are more "lift like" however.
>
> Cheers, Tim
>
> On 29/05/2009 10:21, "marius d."  wrote:
>
>>
>> I think that would be really good. But I'd rather not use annotations.
>> Personally I find closures approach a much better fit here.
>>
>> withTxRequired {
>>   ... // do transational stuff
>>
>> }
>>
>>
>> Br's,
>> Marius
>>
>> On May 29, 11:55 am, Jonas Bonér  wrote:
>>> Hi guys.
>>>
>>> I have been talking with David Pollak the rest of the lift team about
>>> adding JTA to Lift. I have implemented that for a product written in
>>> Scala some time ago. Now some of that code is OSS
>>> at:http://github.com/jboner/skalman/tree
>>>
>>> We used using two different APIs.
>>> 1. Annotations (would require Lift to support proxied objects, e.g.
>>> grab them from a factory):
>>>
>>> @TransactionAttribute(REQUIRED)
>>> def transactionalMethod = { ... }
>>>
>>> 2. Call-by-name:
>>>
>>> withTxRequired {
>>>   ... // do transational stuff
>>>
>>> }
>>>
>>> But I don't know what fits Lift and would like to know how you guys
>>> would like to have JTA integrated.
>>> At which level? Which APIs? Etc.
>>>
>>> --
>>> Jonas Bonér
>>>
>>> twitter: @jboner
>>> blog:    http://jonasboner.com
>>> work:  http://crisp.se
>>> work:  http://scalablesolutions.se
>>> code:  http://github.com/jboner
>> >
>>
>
>
>
> >
>



-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

--~--~-~--~~~---~--~~
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: How to disable jQuery from lift application?

[David Pollak]

On Fri, May 29, 2009 at 1:23 AM, Narayanaswamy, Mohan <
mohan.narayanasw...@credit-suisse.com> wrote:

>
> I will try to send one, But Google API was failing while trying to load
> banner.


I suspect the problem is that Lift renders pages as strict XHTML and sets
the mime type of responses to be application/xhtml+xml  This imposes much
stricter requirements on dynamically generated HTML.  Google Maps does not
work in this mode.  In Boot.scala try adding this line:

LiftRules.useXhtmlMimeType = false

And see if things work.

Thanks,

David


> Google just released those api's.
>
> Mohan
>
> -Original Message-
> From: liftweb@googlegroups.com [mailto:lift...@googlegroups.com] On Behalf
> Of Narayanaswamy, Mohan
> Sent: 28 May 2009 00:32
> To: Lift
> Subject: [Lift] Re: How to disable jQuery from lift application?
>
>
> As per my limited knowledge, Google javascript API fails. Below API, I am
> using it to transfer "English to Tamil" tranliteration.
>
> Webpage error details
>
> Message: Unexpected call to method or property access.
> Line: 22
> Char: 388
> Code: 0
> URI:
> http://www.google.com/uds/api/elements/1.0/1aac8bdeb1f85e7c5035029a61994691/transliteration.I.js
>
>
> Mohan
>
> On May 27, 8:21 pm, David Pollak 
> wrote:
> > Mohan,
> >
> > Marius answered your question, but I'm curious... how does jQuery
> > conflict with the google library?  What kind of errors are you seeing?
> >
> > Thanks,
> >
> > David
> >
> > On Tue, May 26, 2009 at 5:50 PM, KaniniPazham <
> >
> >
> >
> >
> >
> > mohan.narayanasw...@credit-suisse.com> wrote:
> >
> > > I am using  "Archetype basic" and in my form, I am trying to
> > > integrate with Google Transliteration API. So in one of the page, I
> > > would like to disable jQuery as it conflicts with google
> Transliteration API.
> >
> > > I found following function is generated and added automatically,
> > > they are not in my template.
> >
> > >  //  > > jQuery(document).ready(function() {lift_successRegisterGC();}); var
> > > lift_page = 'F27052369736502T'; // ]]> 
> >
> > > How could I disable generating such a automatic jQuery script?
> > > How could I disable jQuery for whole LiftApplication?
> > > How could I disable jQuery for only one page?
> >
> > > Extremely sorry if the above questions are simple and stupid. Except
> > > Core-java, everything is new to me.
> >
> > > Mohan
> >
> > --
> > 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- Hide quoted text -
> >
> > - Show quoted text -
>
>
>
>
>
> ==
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
>
> ==
>
>
> >
>


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

[Derek Chen-Becker]

I'd vote for closures. We use annotations for JPA because we have to, but
IMHO closures provide a nicer semantic approach because they syntactically
enclose the block where the action is occurring.

Derek

On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:

>
> No perf difference. The annotations are turned into the same exact
> closures.
>
> 2009/5/29 Timothy Perrett :
> >
> >
> > Are there any performance implications considering closures vs
> annotations?
> > Agreed that closures are more "lift like" however.
> >
> > Cheers, Tim
> >
> > On 29/05/2009 10:21, "marius d."  wrote:
> >
> >>
> >> I think that would be really good. But I'd rather not use annotations.
> >> Personally I find closures approach a much better fit here.
> >>
> >> withTxRequired {
> >>   ... // do transational stuff
> >>
> >> }
> >>
> >>
> >> Br's,
> >> Marius
> >>
> >> On May 29, 11:55 am, Jonas Bonér  wrote:
> >>> Hi guys.
> >>>
> >>> I have been talking with David Pollak the rest of the lift team about
> >>> adding JTA to Lift. I have implemented that for a product written in
> >>> Scala some time ago. Now some of that code is OSS
> >>> at:http://github.com/jboner/skalman/tree
> >>>
> >>> We used using two different APIs.
> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
> >>> grab them from a factory):
> >>>
> >>> @TransactionAttribute(REQUIRED)
> >>> def transactionalMethod = { ... }
> >>>
> >>> 2. Call-by-name:
> >>>
> >>> withTxRequired {
> >>>   ... // do transational stuff
> >>>
> >>> }
> >>>
> >>> But I don't know what fits Lift and would like to know how you guys
> >>> would like to have JTA integrated.
> >>> At which level? Which APIs? Etc.
> >>>
> >>> --
> >>> Jonas Bonér
> >>>
> >>> twitter: @jboner
> >>> blog:http://jonasboner.com
> >>> work:  http://crisp.se
> >>> work:  http://scalablesolutions.se
> >>> code:  http://github.com/jboner
> >> >
> >>
> >
> >
> >
> > >
> >
>
>
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog:http://jonasboner.com
> work:   http://crisp.se
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
>
> >
>

--~--~-~--~~~---~--~~
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: Record with the new bind-immutable

[Oliver Lambert]

That would be very cool

On Fri, May 29, 2009 at 11:37 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

> One thing I've been thinking about is optionally extending the Validator
> Functions to also emit JavaScript that would perform the validation in the
> browser... that would provide a seamless way to do client-side validation
> for validators (e.g., min len, max len, regex) that only rely on client-side
> data.
>
>
> On Fri, May 29, 2009 at 6:32 AM, Oliver Lambert wrote:
>
>> Hi Marius,
>> To try and answer your question, I had to go and look at the Record code
>> in
>> more detail. I hadn't recently written the Binder Validator, so it wasn't
>> designed to be
>> complementary to anything else (however, some of the naming and
>> methodology is very
>> similar in both sets of code).
>>
>> What I found.
>> 1) MetaRecord.validate === Binder.validate
>> 2) Field.validators === BoundObj.validations
>> 3) Field.validationFunction === Validator.validate
>> 4) List[FieldError]  === List[ValidationError]
>>
>> Can I get rid of Binder Validation and just use Record/Field validation?
>> It certainly looks like I should try. However, I might have to add/change
>> some of the original Lift code.
>> For instance, I might want to add an errorType (with a default, so no code
>> is broken) to FieldError.
>> I might also want to move/change Field.validationFunction so its a little
>> more
>> like my Validator,with an errorType and toString (When I print my
>> validators, the errorType give a little
>> information on what they do, rather than just telling me I have a function
>> - I also filter using
>> the errorType)
>>
>> Other things of interest that I found.
>>
>> Could a Binder be a MetaRecord? There are definitely some similarities.
>> Binder holds a set of
>> immutable objects which can be an advantage, but MetaRecord can talk to
>> databases which is
>> kind of useful at times.
>>
>> Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may
>> hold a reference to a string value
>> that is completely invalid. I'm not sure I see this in Field.
>>
>> cheers
>> Oliver
>>
>> On Fri, May 29, 2009 at 6:22 PM, marius d. wrote:
>>
>>>
>>> I see ... still the question remains. What are we going to do with two
>>> validators? I'd like to understand the principles of your addition
>>> (... I know I should have dig into the code but I don't have much time
>>> now).
>>>
>>> I'd like to understand as I said previously if we have redundant
>>> validators or complementary functionality so that people to not get
>>> confused.
>>>
>>> I'm not trying at all to be negative or anything, just trying to
>>> understand the value added.
>>>
>>> Br's,
>>> Marius
>>>
>>> On May 29, 11:01 am, Oliver Lambert  wrote:
>>> > I'm aware of S.error and my ValidationError uses it when I'm ready to
>>> show
>>> > errors. I've briefly looked at the ValidationFunction and the thing I
>>> might
>>> > stumble on is the errorType which I rely on.
>>> >
>>> > I may be able to refactor the code to use List[FieldError] as I don't
>>> think
>>> > I rely on errorType at this point.
>>> >
>>> > I'll have a go at modifying the Binder code.
>>> >
>>> > cheers
>>> > Oliver
>>> >
>>> > On Fri, May 29, 2009 at 5:05 PM, Marius 
>>> wrote:
>>> >
>>> > > Oliver,
>>> >
>>> > > I very briefly looked on your code and I saw that you have your own
>>> > > validator there. How would that play with the existent validattors
>>> > > that Record has where each field has a list of :
>>> >
>>> > > type ValidationFunction = MyType => Box[Node]
>>> >
>>> > > Note that current MetaRecord's validator after evaluating the
>>> > > validators for each field it yields a List[FieldError] which can be
>>> > > easily naturally used with S.error function to show the error
>>> messages
>>> > > etc.
>>> >
>>> > > Is there a redundancy or complementary functionality?
>>> >
>>> > > Br's,
>>> > > Marius
>>>
>>>
>>
>>
>>
>
>
> --
> 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: JTA

[David Pollak]

On Fri, May 29, 2009 at 6:47 AM, Derek Chen-Becker wrote:

> I'd vote for closures. We use annotations for JPA because we have to, but
> IMHO closures provide a nicer semantic approach because they syntactically
> enclose the block where the action is occurring.


I view annotations as a "second language" within the language.  They have
syntax and semantics that are unique to each annotation and they require
extra tool chain support.  I prefer to express things in the native syntax
of the language, so the closure approach is my vote.


>
>
> Derek
>
>
> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>
>>
>> No perf difference. The annotations are turned into the same exact
>> closures.
>>
>> 2009/5/29 Timothy Perrett :
>> >
>> >
>> > Are there any performance implications considering closures vs
>> annotations?
>> > Agreed that closures are more "lift like" however.
>> >
>> > Cheers, Tim
>> >
>> > On 29/05/2009 10:21, "marius d."  wrote:
>> >
>> >>
>> >> I think that would be really good. But I'd rather not use annotations.
>> >> Personally I find closures approach a much better fit here.
>> >>
>> >> withTxRequired {
>> >>   ... // do transational stuff
>> >>
>> >> }
>> >>
>> >>
>> >> Br's,
>> >> Marius
>> >>
>> >> On May 29, 11:55 am, Jonas Bonér  wrote:
>> >>> Hi guys.
>> >>>
>> >>> I have been talking with David Pollak the rest of the lift team about
>> >>> adding JTA to Lift. I have implemented that for a product written in
>> >>> Scala some time ago. Now some of that code is OSS
>> >>> at:http://github.com/jboner/skalman/tree
>> >>>
>> >>> We used using two different APIs.
>> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> >>> grab them from a factory):
>> >>>
>> >>> @TransactionAttribute(REQUIRED)
>> >>> def transactionalMethod = { ... }
>> >>>
>> >>> 2. Call-by-name:
>> >>>
>> >>> withTxRequired {
>> >>>   ... // do transational stuff
>> >>>
>> >>> }
>> >>>
>> >>> But I don't know what fits Lift and would like to know how you guys
>> >>> would like to have JTA integrated.
>> >>> At which level? Which APIs? Etc.
>> >>>
>> >>> --
>> >>> Jonas Bonér
>> >>>
>> >>> twitter: @jboner
>> >>> blog:http://jonasboner.com
>> >>> work:  http://crisp.se
>> >>> work:  http://scalablesolutions.se
>> >>> code:  http://github.com/jboner
>> >> >
>> >>
>> >
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>>
>
> >
>


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

[Jonas Bonér]

I'll go for closures. Much simpler and less intrusive into Lift.
The current impl is based on Atomikos and Hibernate, I'll start with
pushing that in and we can make it pluggable later.
For example for Hibernate one need to add a line to the hibernate
config to register the
org.hibernate.transaction.TransactionManagerLookup class in order to
make Hibernate aware of our TX manager.

Should I fork the github repo and submit patches or how do you guys work?

/Jonas


2009/5/29 Derek Chen-Becker :
> I'd vote for closures. We use annotations for JPA because we have to, but
> IMHO closures provide a nicer semantic approach because they syntactically
> enclose the block where the action is occurring.
>
> Derek
>
> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>>
>> No perf difference. The annotations are turned into the same exact
>> closures.
>>
>> 2009/5/29 Timothy Perrett :
>> >
>> >
>> > Are there any performance implications considering closures vs
>> > annotations?
>> > Agreed that closures are more "lift like" however.
>> >
>> > Cheers, Tim
>> >
>> > On 29/05/2009 10:21, "marius d."  wrote:
>> >
>> >>
>> >> I think that would be really good. But I'd rather not use annotations.
>> >> Personally I find closures approach a much better fit here.
>> >>
>> >> withTxRequired {
>> >>   ... // do transational stuff
>> >>
>> >> }
>> >>
>> >>
>> >> Br's,
>> >> Marius
>> >>
>> >> On May 29, 11:55 am, Jonas Bonér  wrote:
>> >>> Hi guys.
>> >>>
>> >>> I have been talking with David Pollak the rest of the lift team about
>> >>> adding JTA to Lift. I have implemented that for a product written in
>> >>> Scala some time ago. Now some of that code is OSS
>> >>> at:http://github.com/jboner/skalman/tree
>> >>>
>> >>> We used using two different APIs.
>> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> >>> grab them from a factory):
>> >>>
>> >>> @TransactionAttribute(REQUIRED)
>> >>> def transactionalMethod = { ... }
>> >>>
>> >>> 2. Call-by-name:
>> >>>
>> >>> withTxRequired {
>> >>>   ... // do transational stuff
>> >>>
>> >>> }
>> >>>
>> >>> But I don't know what fits Lift and would like to know how you guys
>> >>> would like to have JTA integrated.
>> >>> At which level? Which APIs? Etc.
>> >>>
>> >>> --
>> >>> Jonas Bonér
>> >>>
>> >>> twitter: @jboner
>> >>> blog:    http://jonasboner.com
>> >>> work:  http://crisp.se
>> >>> work:  http://scalablesolutions.se
>> >>> code:  http://github.com/jboner
>> >> >
>> >>
>> >
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:    http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>
>
> >
>



-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

--~--~-~--~~~---~--~~
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: JTA

[Timothy Perrett]

Committers can work on branches. The general solution is that if you are
working on something that is "new" or "dangerous" use a branch with the
following naming convention:

wip--

E.g. wip-tim-localization

Checkout the thread oliver started "git ouch" - I just posted instructions
there for creating branches on the lift repo for committers.

Good luck.

Cheers, Tim



On 29/05/2009 14:54, "Jonas Bonér"  wrote:

> 
> I'll go for closures. Much simpler and less intrusive into Lift.
> The current impl is based on Atomikos and Hibernate, I'll start with
> pushing that in and we can make it pluggable later.
> For example for Hibernate one need to add a line to the hibernate
> config to register the
> org.hibernate.transaction.TransactionManagerLookup class in order to
> make Hibernate aware of our TX manager.
> 
> Should I fork the github repo and submit patches or how do you guys work?
> 
> /Jonas
> 
> 
> 2009/5/29 Derek Chen-Becker :
>> I'd vote for closures. We use annotations for JPA because we have to, but
>> IMHO closures provide a nicer semantic approach because they syntactically
>> enclose the block where the action is occurring.
>> 
>> Derek
>> 
>> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>>> 
>>> No perf difference. The annotations are turned into the same exact
>>> closures.
>>> 
>>> 2009/5/29 Timothy Perrett :
 
 
 Are there any performance implications considering closures vs
 annotations?
 Agreed that closures are more "lift like" however.
 
 Cheers, Tim
 
 On 29/05/2009 10:21, "marius d."  wrote:
 
> 
> I think that would be really good. But I'd rather not use annotations.
> Personally I find closures approach a much better fit here.
> 
> withTxRequired {
>   ... // do transational stuff
> 
> }
> 
> 
> Br's,
> Marius
> 
> On May 29, 11:55 am, Jonas Bonér  wrote:
>> Hi guys.
>> 
>> I have been talking with David Pollak the rest of the lift team about
>> adding JTA to Lift. I have implemented that for a product written in
>> Scala some time ago. Now some of that code is OSS
>> at:http://github.com/jboner/skalman/tree
>> 
>> We used using two different APIs.
>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> grab them from a factory):
>> 
>> @TransactionAttribute(REQUIRED)
>> def transactionalMethod = { ... }
>> 
>> 2. Call-by-name:
>> 
>> withTxRequired {
>>   ... // do transational stuff
>> 
>> }
>> 
>> But I don't know what fits Lift and would like to know how you guys
>> would like to have JTA integrated.
>> At which level? Which APIs? Etc.
>> 
>> --
>> Jonas Bonér
>> 
>> twitter: @jboner
>> blog:    http://jonasboner.com
>> work:  http://crisp.se
>> work:  http://scalablesolutions.se
>> code:  http://github.com/jboner
>> 
> 
 
 
 
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Jonas Bonér
>>> 
>>> twitter: @jboner
>>> blog:    http://jonasboner.com
>>> work:   http://crisp.se
>>> work:   http://scalablesolutions.se
>>> code:   http://github.com/jboner
>>> 
>>> 
>> 
>> 
>>> 
>> 
> 
> 



--~--~-~--~~~---~--~~
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: JTA

[Derek Chen-Becker]

Create a branch (see Oliver's recent thread) and push that. We cna look at
the branch before merging into master. Branching is preferred over forking
because it keeps things in the same stream.

Derek

On Fri, May 29, 2009 at 7:54 AM, Jonas Bonér  wrote:

>
> I'll go for closures. Much simpler and less intrusive into Lift.
> The current impl is based on Atomikos and Hibernate, I'll start with
> pushing that in and we can make it pluggable later.
> For example for Hibernate one need to add a line to the hibernate
> config to register the
> org.hibernate.transaction.TransactionManagerLookup class in order to
> make Hibernate aware of our TX manager.
>
> Should I fork the github repo and submit patches or how do you guys work?
>
> /Jonas
>
>
> 2009/5/29 Derek Chen-Becker :
> > I'd vote for closures. We use annotations for JPA because we have to, but
> > IMHO closures provide a nicer semantic approach because they
> syntactically
> > enclose the block where the action is occurring.
> >
> > Derek
> >
> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
> >>
> >> No perf difference. The annotations are turned into the same exact
> >> closures.
> >>
> >> 2009/5/29 Timothy Perrett :
> >> >
> >> >
> >> > Are there any performance implications considering closures vs
> >> > annotations?
> >> > Agreed that closures are more "lift like" however.
> >> >
> >> > Cheers, Tim
> >> >
> >> > On 29/05/2009 10:21, "marius d."  wrote:
> >> >
> >> >>
> >> >> I think that would be really good. But I'd rather not use
> annotations.
> >> >> Personally I find closures approach a much better fit here.
> >> >>
> >> >> withTxRequired {
> >> >>   ... // do transational stuff
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >> Br's,
> >> >> Marius
> >> >>
> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
> >> >>> Hi guys.
> >> >>>
> >> >>> I have been talking with David Pollak the rest of the lift team
> about
> >> >>> adding JTA to Lift. I have implemented that for a product written in
> >> >>> Scala some time ago. Now some of that code is OSS
> >> >>> at:http://github.com/jboner/skalman/tree
> >> >>>
> >> >>> We used using two different APIs.
> >> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
> >> >>> grab them from a factory):
> >> >>>
> >> >>> @TransactionAttribute(REQUIRED)
> >> >>> def transactionalMethod = { ... }
> >> >>>
> >> >>> 2. Call-by-name:
> >> >>>
> >> >>> withTxRequired {
> >> >>>   ... // do transational stuff
> >> >>>
> >> >>> }
> >> >>>
> >> >>> But I don't know what fits Lift and would like to know how you guys
> >> >>> would like to have JTA integrated.
> >> >>> At which level? Which APIs? Etc.
> >> >>>
> >> >>> --
> >> >>> Jonas Bonér
> >> >>>
> >> >>> twitter: @jboner
> >> >>> blog:http://jonasboner.com
> >> >>> work:  http://crisp.se
> >> >>> work:  http://scalablesolutions.se
> >> >>> code:  http://github.com/jboner
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Jonas Bonér
> >>
> >> twitter: @jboner
> >> blog:http://jonasboner.com
> >> work:   http://crisp.se
> >> work:   http://scalablesolutions.se
> >> code:   http://github.com/jboner
> >>
> >>
> >
> >
> > >
> >
>
>
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog:http://jonasboner.com
> work:   http://crisp.se
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
>
> >
>

--~--~-~--~~~---~--~~
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: JTA

[Jonas Bonér]

Thanks Tim and Derek.
I'll work in a branch. Simpler for me as well.
/Jonas

2009/5/29 Timothy Perrett :
>
>
> Committers can work on branches. The general solution is that if you are
> working on something that is "new" or "dangerous" use a branch with the
> following naming convention:
>
> wip--
>
> E.g. wip-tim-localization
>
> Checkout the thread oliver started "git ouch" - I just posted instructions
> there for creating branches on the lift repo for committers.
>
> Good luck.
>
> Cheers, Tim
>
>
>
> On 29/05/2009 14:54, "Jonas Bonér"  wrote:
>
>>
>> I'll go for closures. Much simpler and less intrusive into Lift.
>> The current impl is based on Atomikos and Hibernate, I'll start with
>> pushing that in and we can make it pluggable later.
>> For example for Hibernate one need to add a line to the hibernate
>> config to register the
>> org.hibernate.transaction.TransactionManagerLookup class in order to
>> make Hibernate aware of our TX manager.
>>
>> Should I fork the github repo and submit patches or how do you guys work?
>>
>> /Jonas
>>
>>
>> 2009/5/29 Derek Chen-Becker :
>>> I'd vote for closures. We use annotations for JPA because we have to, but
>>> IMHO closures provide a nicer semantic approach because they syntactically
>>> enclose the block where the action is occurring.
>>>
>>> Derek
>>>
>>> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:

 No perf difference. The annotations are turned into the same exact
 closures.

 2009/5/29 Timothy Perrett :
>
>
> Are there any performance implications considering closures vs
> annotations?
> Agreed that closures are more "lift like" however.
>
> Cheers, Tim
>
> On 29/05/2009 10:21, "marius d."  wrote:
>
>>
>> I think that would be really good. But I'd rather not use annotations.
>> Personally I find closures approach a much better fit here.
>>
>> withTxRequired {
>>   ... // do transational stuff
>>
>> }
>>
>>
>> Br's,
>> Marius
>>
>> On May 29, 11:55 am, Jonas Bonér  wrote:
>>> Hi guys.
>>>
>>> I have been talking with David Pollak the rest of the lift team about
>>> adding JTA to Lift. I have implemented that for a product written in
>>> Scala some time ago. Now some of that code is OSS
>>> at:http://github.com/jboner/skalman/tree
>>>
>>> We used using two different APIs.
>>> 1. Annotations (would require Lift to support proxied objects, e.g.
>>> grab them from a factory):
>>>
>>> @TransactionAttribute(REQUIRED)
>>> def transactionalMethod = { ... }
>>>
>>> 2. Call-by-name:
>>>
>>> withTxRequired {
>>>   ... // do transational stuff
>>>
>>> }
>>>
>>> But I don't know what fits Lift and would like to know how you guys
>>> would like to have JTA integrated.
>>> At which level? Which APIs? Etc.
>>>
>>> --
>>> Jonas Bonér
>>>
>>> twitter: @jboner
>>> blog:    http://jonasboner.com
>>> work:  http://crisp.se
>>> work:  http://scalablesolutions.se
>>> code:  http://github.com/jboner
>>>
>>
>
>
>
>>
>



 --
 Jonas Bonér

 twitter: @jboner
 blog:    http://jonasboner.com
 work:   http://crisp.se
 work:   http://scalablesolutions.se
 code:   http://github.com/jboner


>>>
>>>

>>>
>>
>>
>
>
>
> >
>



-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

--~--~-~--~~~---~--~~
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] How important is AJAX to you?

[Joe Wass]

This may be heresy on this list, but I'll ask it anyway. A general
point for discussion which I'm raising because the Lift Book mentions
AJAX early on in the PocketChange app.

How important is AJAX and all the associated Web 2.0 stuff to you and
to your projects? I'm quite happy without Javascript and AJAX. More
often than not they're doing the kind of thing you could just as
easily do with traditional technologies. Save for one web-app (Google
Mail), I don't think a single site I use has been improved for it.
Particular examples are Slashdot and Facebook. Give me good old HTML
any day.

I've got a few projects in the pipeline and I intend to use Lift for
all of them, it looks excellent and from the source I've read very
nicely engineered. But I will expressly avoid using anything other
than old-fashioned HTML as much as I can, largely because I'm
targetting browsers of unknown vintage in less economically developed
countries and I'd like to be able to use my own site without cookies
or javascript if I want to.

Have I missed the point of Lift entirely? Am I in a small minority? Am
I crazy?

Joe

--~--~-~--~~~---~--~~
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: How important is AJAX to you?

[Jeremy Day]

All,

I have a slightly related question.  I'm new to the list and a complete
newbie to Lift (having only discovered it a couple of days ago), so forgive
me for the potentially silly question.  Can you use Lift with Flex for the
front end, rather than HTML/CSS/javascript?

Jeremy

On Fri, May 29, 2009 at 9:58 AM, Joe Wass  wrote:

>
> This may be heresy on this list, but I'll ask it anyway. A general
> point for discussion which I'm raising because the Lift Book mentions
> AJAX early on in the PocketChange app.
>
> How important is AJAX and all the associated Web 2.0 stuff to you and
> to your projects? I'm quite happy without Javascript and AJAX. More
> often than not they're doing the kind of thing you could just as
> easily do with traditional technologies. Save for one web-app (Google
> Mail), I don't think a single site I use has been improved for it.
> Particular examples are Slashdot and Facebook. Give me good old HTML
> any day.
>
> I've got a few projects in the pipeline and I intend to use Lift for
> all of them, it looks excellent and from the source I've read very
> nicely engineered. But I will expressly avoid using anything other
> than old-fashioned HTML as much as I can, largely because I'm
> targetting browsers of unknown vintage in less economically developed
> countries and I'd like to be able to use my own site without cookies
> or javascript if I want to.
>
> Have I missed the point of Lift entirely? Am I in a small minority? Am
> I crazy?
>
> Joe
>
> >
>

--~--~-~--~~~---~--~~
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: How important is AJAX to you?

[David Pollak]

On Fri, May 29, 2009 at 8:41 AM, Jeremy Day  wrote:

> All,
>
> I have a slightly related question.  I'm new to the list and a complete
> newbie to Lift (having only discovered it a couple of days ago), so forgive
> me for the potentially silly question.  Can you use Lift with Flex for the
> front end, rather than HTML/CSS/javascript?


Yes.  It tooks about 2 hours of coding when we unified the DHTML and Flash
versions of http://buyafeature.com to use the same APIs (it way mostly
removing hard-coded HTML from the API handlers.)

It was less than an hour when we moved ESME (
http://incubator.apache.org/esme/ ) from serving HTML to serving JSON
objects (although at this point, the view is rendered via JavaScript as
HTML, but the server doesn't know that.)


>
>
> Jeremy
>
>
> On Fri, May 29, 2009 at 9:58 AM, Joe Wass  wrote:
>
>>
>> This may be heresy on this list, but I'll ask it anyway. A general
>> point for discussion which I'm raising because the Lift Book mentions
>> AJAX early on in the PocketChange app.
>>
>> How important is AJAX and all the associated Web 2.0 stuff to you and
>> to your projects? I'm quite happy without Javascript and AJAX. More
>> often than not they're doing the kind of thing you could just as
>> easily do with traditional technologies. Save for one web-app (Google
>> Mail), I don't think a single site I use has been improved for it.
>> Particular examples are Slashdot and Facebook. Give me good old HTML
>> any day.
>>
>> I've got a few projects in the pipeline and I intend to use Lift for
>> all of them, it looks excellent and from the source I've read very
>> nicely engineered. But I will expressly avoid using anything other
>> than old-fashioned HTML as much as I can, largely because I'm
>> targetting browsers of unknown vintage in less economically developed
>> countries and I'd like to be able to use my own site without cookies
>> or javascript if I want to.
>>
>> Have I missed the point of Lift entirely? Am I in a small minority? Am
>> I crazy?
>>
>> Joe
>>
>>
>>
>
> >
>


-- 
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: How important is AJAX to you?

[David Pollak]

On Fri, May 29, 2009 at 7:58 AM, Joe Wass  wrote:

>
> This may be heresy on this list, but I'll ask it anyway. A general
> point for discussion which I'm raising because the Lift Book mentions
> AJAX early on in the PocketChange app.
>
> How important is AJAX and all the associated Web 2.0 stuff to you and
> to your projects? I'm quite happy without Javascript and AJAX. More
> often than not they're doing the kind of thing you could just as
> easily do with traditional technologies. Save for one web-app (Google
> Mail), I don't think a single site I use has been improved for it.
> Particular examples are Slashdot and Facebook. Give me good old HTML
> any day.
>
> I've got a few projects in the pipeline and I intend to use Lift for
> all of them, it looks excellent and from the source I've read very
> nicely engineered. But I will expressly avoid using anything other
> than old-fashioned HTML as much as I can, largely because I'm
> targetting browsers of unknown vintage in less economically developed
> countries and I'd like to be able to use my own site without cookies
> or javascript if I want to.
>
> Have I missed the point of Lift entirely?


I think that a key take-away from Lift is the abstraction of the HTTP
request/response cycle so that higher level abstractions can happen...
basically, freeing the developer to focus on the business task at hand
rather than the plumbing of HTTP.  This requires state which means cookies.
 It does not require Ajax.


> Am I in a small minority? Am
> I crazy?
>
> Joe
>
> >
>


-- 
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: Record with the new bind-immutable

[marius d.]

On May 29, 4:32 pm, Oliver Lambert  wrote:
> Hi Marius,
> To try and answer your question, I had to go and look at the Record code in
> more detail. I hadn't recently written the Binder Validator, so it wasn't
> designed to be
> complementary to anything else (however, some of the naming and methodology
> is very
> similar in both sets of code).
>
> What I found.
> 1) MetaRecord.validate     === Binder.validate
> 2) Field.validators             === BoundObj.validations
> 3) Field.validationFunction === Validator.validate
> 4) List[FieldError]              === List[ValidationError]
>
> Can I get rid of Binder Validation and just use Record/Field validation?
> It certainly looks like I should try. However, I might have to add/change
> some of the original Lift code.
> For instance, I might want to add an errorType (with a default, so no code
> is broken) to FieldError.
> I might also want to move/change Field.validationFunction so its a little
> more
> like my Validator,with an errorType and toString (When I print my
> validators, the errorType give a little
> information on what they do, rather than just telling me I have a function -
> I also filter using
> the errorType)

I think we should unify the models. What I particularly like about the
existent validators is that it rlies on function type hence the
flexibility to use anonymous functions or existent ones. SO IMHO it
would be really neat to keep the existent validators per Field and if
you would edd the errorType support would just great.

Oh FWIW I'm not a fan of function names starting with capital letters
such as: def Range(lower: Int, upper: Int, errStr: String)  .. but
that's just me.

>
> Other things of interest that I found.
>
> Could a Binder be a MetaRecord? There are definitely some similarities.
> Binder holds a set of
> immutable objects which can be an advantage, but MetaRecord can talk to
> databases which is
> kind of useful at times.

I think we should keep the Meta Record and Record. Please keep in mind
that MetaRecord and Record have NOTHING to do with database, they are
completely separated per design so that Records can be also used
outside of a RDBMS scope. For DB we have DBMetaRecord and DBRecord
which are not fully implemented yet.

>
> Could a BoundObj be a Field. Same distinction as above. A BoundObj[T] may
> hold a reference to a string value
> that is completely invalid. I'm not sure I see this in Field.


IMHO I would just add the features that your code has and current code
does not (such as error type) and put them in the MetaRecord/Record
(or wherever they belong) and have a single coherent model. Please
also take a deeper look on the existent code, in MetaRecord, Record,
Fields implementations Not DB Fields) and see what goodies can be
added from your new code.

And integrating client side validations (as Dave suggested) in the
same model would be really cool.

>
> cheers
> Oliver
>
> On Fri, May 29, 2009 at 6:22 PM, marius d.  wrote:
>
> > I see ... still the question remains. What are we going to do with two
> > validators? I'd like to understand the principles of your addition
> > (... I know I should have dig into the code but I don't have much time
> > now).
>
> > I'd like to understand as I said previously if we have redundant
> > validators or complementary functionality so that people to not get
> > confused.
>
> > I'm not trying at all to be negative or anything, just trying to
> > understand the value added.
>
> > Br's,
> > Marius
>
> > On May 29, 11:01 am, Oliver Lambert  wrote:
> > > I'm aware of S.error and my ValidationError uses it when I'm ready to
> > show
> > > errors. I've briefly looked at the ValidationFunction and the thing I
> > might
> > > stumble on is the errorType which I rely on.
>
> > > I may be able to refactor the code to use List[FieldError] as I don't
> > think
> > > I rely on errorType at this point.
>
> > > I'll have a go at modifying the Binder code.
>
> > > cheers
> > > Oliver
>
> > > On Fri, May 29, 2009 at 5:05 PM, Marius  wrote:
>
> > > > Oliver,
>
> > > > I very briefly looked on your code and I saw that you have your own
> > > > validator there. How would that play with the existent validattors
> > > > that Record has where each field has a list of :
>
> > > > type ValidationFunction = MyType => Box[Node]
>
> > > > Note that current MetaRecord's validator after evaluating the
> > > > validators for each field it yields a List[FieldError] which can be
> > > > easily naturally used with S.error function to show the error messages
> > > > etc.
>
> > > > Is there a redundancy or complementary functionality?
>
> > > > Br's,
> > > > Marius
--~--~-~--~~~---~--~~
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.googl

[Lift] Re: How important is AJAX to you?

[Timothy Perrett]

Appreciate you are a busy man David, but from a community perspective I
think it would be awesome if you could pour some of your brain into a
whitepaper on this subject ­ your very right, its a key take away and an
important part of lifts ³sales pitch² as it were.

Cheers, Tim

On 29/05/2009 17:00, "David Pollak"  wrote:

> I think that a key take-away from Lift is the abstraction of the HTTP
> request/response cycle so that higher level abstractions can happen...
> basically, freeing the developer to focus on the business task at hand rather
> than the plumbing of HTTP.  This requires state which means cookies.  It does
> not require Ajax.  
>  


--~--~-~--~~~---~--~~
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: How important is AJAX to you?

[marius d.]

You can use Lift perfectly fine without Ajax, javaScript or even
cookies. If you're turning off cookies from the container relative
paths for links, forms etc. will be provided with JSESSIONID quantity
for you so you don't have to do anything. This is otherwise known as
URL rewriting. So you can still have the same context semantics but
referred from URI not cookies.

Br's,
Marius

On May 29, 7:00 pm, David Pollak 
wrote:
> On Fri, May 29, 2009 at 7:58 AM, Joe Wass  wrote:
>
> > This may be heresy on this list, but I'll ask it anyway. A general
> > point for discussion which I'm raising because the Lift Book mentions
> > AJAX early on in the PocketChange app.
>
> > How important is AJAX and all the associated Web 2.0 stuff to you and
> > to your projects? I'm quite happy without Javascript and AJAX. More
> > often than not they're doing the kind of thing you could just as
> > easily do with traditional technologies. Save for one web-app (Google
> > Mail), I don't think a single site I use has been improved for it.
> > Particular examples are Slashdot and Facebook. Give me good old HTML
> > any day.
>
> > I've got a few projects in the pipeline and I intend to use Lift for
> > all of them, it looks excellent and from the source I've read very
> > nicely engineered. But I will expressly avoid using anything other
> > than old-fashioned HTML as much as I can, largely because I'm
> > targetting browsers of unknown vintage in less economically developed
> > countries and I'd like to be able to use my own site without cookies
> > or javascript if I want to.
>
> > Have I missed the point of Lift entirely?
>
> I think that a key take-away from Lift is the abstraction of the HTTP
> request/response cycle so that higher level abstractions can happen...
> basically, freeing the developer to focus on the business task at hand
> rather than the plumbing of HTTP.  This requires state which means cookies.
>  It does not require Ajax.
>
> > Am I in a small minority? Am
> > I crazy?
>
> > Joe
>
> --
> 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: How important is AJAX to you?

[Randall R Schulz]

On Friday May 29 2009, Joe Wass wrote:
> ...
>
> Have I missed the point of Lift entirely? Am I in a small minority?
> Am I crazy?

Perhaps. Perhaps. Probably not (but who really knows?)

Seriously, my interest in Lift (and Grails before it—don't shoot me) is 
in providing what I call BBIs (browser-based interfaces) as a 
completely competitive alternative to standard GUIs. Thus AJAX (by any 
name) is a necessity.

If your user base dictates strict page-load-per-interaction designs, 
that's your call. Only you know your requirements. But I think the bulk 
of new Web App development henceforward will make ever-increasing use 
of AJAX techniques. It's why Google is developing Chrome, after all.


> Joe


Randall Schulz

--~--~-~--~~~---~--~~
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: How to disable jQuery from lift application?

[Charles F. Munat]

The thing that doesn't work, IIRC, is that application/xhtml+xml doesn't 
allow document.write(). The Google code (foolishly, IMO) depends on 
write() to write script elements to the page. For some things you can 
work around it by simply removing the use of write and just adding the 
script elements directly. That's how I've worked around it on my sites.

Chas.

David Pollak wrote:
> 
> 
> On Fri, May 29, 2009 at 1:23 AM, Narayanaswamy, Mohan 
>  > wrote:
> 
> 
> I will try to send one, But Google API was failing while trying to
> load banner.
> 
> 
> I suspect the problem is that Lift renders pages as strict XHTML and 
> sets the mime type of responses to be application/xhtml+xml  This 
> imposes much stricter requirements on dynamically generated HTML. 
>  Google Maps does not work in this mode.  In Boot.scala try adding this 
> line:
> 
> LiftRules.useXhtmlMimeType = false
> 
> And see if things work.
> 
> Thanks,
> 
> David
>  
> 
> Google just released those api's.
> 
> Mohan
> 
> -Original Message-
> From: liftweb@googlegroups.com 
> [mailto:liftweb@googlegroups.com ]
> On Behalf Of Narayanaswamy, Mohan
> Sent: 28 May 2009 00:32
> To: Lift
> Subject: [Lift] Re: How to disable jQuery from lift application?
> 
> 
> As per my limited knowledge, Google javascript API fails. Below API,
> I am using it to transfer "English to Tamil" tranliteration.
> 
> Webpage error details
> 
> Message: Unexpected call to method or property access.
> Line: 22
> Char: 388
> Code: 0
> URI:
> 
> http://www.google.com/uds/api/elements/1.0/1aac8bdeb1f85e7c5035029a61994691/transliteration.I.js
> 
> 
> Mohan
> 
> On May 27, 8:21 pm, David Pollak  >
> wrote:
>  > Mohan,
>  >
>  > Marius answered your question, but I'm curious... how does jQuery
>  > conflict with the google library?  What kind of errors are you
> seeing?
>  >
>  > Thanks,
>  >
>  > David
>  >
>  > On Tue, May 26, 2009 at 5:50 PM, KaniniPazham <
>  >
>  >
>  >
>  >
>  >
>  > mohan.narayanasw...@credit-suisse.com
> > wrote:
>  >
>  > > I am using  "Archetype basic" and in my form, I am trying to
>  > > integrate with Google Transliteration API. So in one of the page, I
>  > > would like to disable jQuery as it conflicts with google
> Transliteration API.
>  >
>  > > I found following function is generated and added automatically,
>  > > they are not in my template.
>  >
>  > >  //   > > jQuery(document).ready(function() {lift_successRegisterGC();}); var
>  > > lift_page = 'F27052369736502T'; // ]]> 
>  >
>  > > How could I disable generating such a automatic jQuery script?
>  > > How could I disable jQuery for whole LiftApplication?
>  > > How could I disable jQuery for only one page?
>  >
>  > > Extremely sorry if the above questions are simple and stupid.
> Except
>  > > Core-java, everything is new to me.
>  >
>  > > Mohan
>  >
>  > --
>  > 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- Hide quoted text -
>  >
>  > - Show quoted text -
> 
> 
> 
> 
> 
> ==
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> 
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> 
> ==
> 
> 
> 
> 
> 
> 
> -- 
> 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: JTA

[Charles F. Munat]

I agree.

Derek Chen-Becker wrote:
> I'd vote for closures. We use annotations for JPA because we have to, 
> but IMHO closures provide a nicer semantic approach because they 
> syntactically enclose the block where the action is occurring.
> 
> Derek
> 
> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  > wrote:
> 
> 
> No perf difference. The annotations are turned into the same exact
> closures.
> 
> 2009/5/29 Timothy Perrett :
>  >
>  >
>  > Are there any performance implications considering closures vs
> annotations?
>  > Agreed that closures are more "lift like" however.
>  >
>  > Cheers, Tim
>  >
>  > On 29/05/2009 10:21, "marius d."  > wrote:
>  >
>  >>
>  >> I think that would be really good. But I'd rather not use
> annotations.
>  >> Personally I find closures approach a much better fit here.
>  >>
>  >> withTxRequired {
>  >>   ... // do transational stuff
>  >>
>  >> }
>  >>
>  >>
>  >> Br's,
>  >> Marius
>  >>
>  >> On May 29, 11:55 am, Jonas Bonér  > wrote:
>  >>> Hi guys.
>  >>>
>  >>> I have been talking with David Pollak the rest of the lift team
> about
>  >>> adding JTA to Lift. I have implemented that for a product
> written in
>  >>> Scala some time ago. Now some of that code is OSS
>  >>> at:http://github.com/jboner/skalman/tree
>  >>>
>  >>> We used using two different APIs.
>  >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>  >>> grab them from a factory):
>  >>>
>  >>> @TransactionAttribute(REQUIRED)
>  >>> def transactionalMethod = { ... }
>  >>>
>  >>> 2. Call-by-name:
>  >>>
>  >>> withTxRequired {
>  >>>   ... // do transational stuff
>  >>>
>  >>> }
>  >>>
>  >>> But I don't know what fits Lift and would like to know how you guys
>  >>> would like to have JTA integrated.
>  >>> At which level? Which APIs? Etc.
>  >>>
>  >>> --
>  >>> Jonas Bonér
>  >>>
>  >>> twitter: @jboner
>  >>> blog:http://jonasboner.com
>  >>> work:  http://crisp.se
>  >>> work:  http://scalablesolutions.se
>  >>> code:  http://github.com/jboner
>  >> >
>  >>
>  >
>  >
>  >
>  > >
>  >
> 
> 
> 
> --
> Jonas Bonér
> 
> twitter: @jboner
> blog:http://jonasboner.com
> work:   http://crisp.se
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
> 
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
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: How important is AJAX to you?

[Charles F. Munat]

Lift makes AJAX easy, but Lift has nothing to do with AJAX. Lift makes a 
lot of things easy.

I've built half a dozen sites in Lift so far, with several more in the 
works, and most of them use no AJAX at all.

That said, there is a lot to be said for AJAX when used properly. I 
think you're way off on that. The problem is (as with pretty much 
everything else on the Web), it's rarely used properly. Google does it 
mostly right. Facebook is mostly a mess.

Chas.

Joe Wass wrote:
> This may be heresy on this list, but I'll ask it anyway. A general
> point for discussion which I'm raising because the Lift Book mentions
> AJAX early on in the PocketChange app.
> 
> How important is AJAX and all the associated Web 2.0 stuff to you and
> to your projects? I'm quite happy without Javascript and AJAX. More
> often than not they're doing the kind of thing you could just as
> easily do with traditional technologies. Save for one web-app (Google
> Mail), I don't think a single site I use has been improved for it.
> Particular examples are Slashdot and Facebook. Give me good old HTML
> any day.
> 
> I've got a few projects in the pipeline and I intend to use Lift for
> all of them, it looks excellent and from the source I've read very
> nicely engineered. But I will expressly avoid using anything other
> than old-fashioned HTML as much as I can, largely because I'm
> targetting browsers of unknown vintage in less economically developed
> countries and I'd like to be able to use my own site without cookies
> or javascript if I want to.
> 
> Have I missed the point of Lift entirely? Am I in a small minority? Am
> I crazy?
> 
> Joe
> 
> > 

--~--~-~--~~~---~--~~
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] Vscaladoc not grokking new documentation

[Derek Chen-Becker]

I've been adding a lot of expanded documentation to S and I just noticed
that there are whole sections that are disappearing. For instance, I
provided the following scaladoc for S.attrs:

  /**
   * Get a list of current attributes. Each attribute item is a pair of
(key,value). The key
   * is an Either that depends on whether the attribute is prefixed or not.
If the attribute
   * is prefixed, the key is a Right((prefix, name)). If the attribute is
unprefixed then the
   * key is a Left(name). For example, the following table shows how various
tag attributes
   * would be represented:
   *
   * 
   *   
   * 
   * List((Left("testname"), "test"))
   *   
   *   
   * 
   * List((Right(("anchor", "name")), "test"))
   *   
   * 
   *
   * The prefixedAttrsToMap method provides a convenient way to retrieve
only attributes with
   * a given prefix. The prefixedAttrsToMetaData method can be used to add
attributes onto an XML
   * node
   *
   * @see #prefixedAttrsToMap(String)
   * @see #prefixedAttrsToMap(String,Map)
   * @see #prefixedAttrsToMetaData(String)
   * @see #prefixedAttrsToMetaData(String,Map)
   */

But the generated documentation for this method is completely empty after
the first sentence:

http://scala-tools.org/mvnsites-snapshots/liftweb/lift-webkit/scaladocs/index.html

Is this a bug or am I writing something wrong in the above comment?

Thanks,

Derek

--~--~-~--~~~---~--~~
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: GAE - working example?

[glenn]

The ant target, runappserver, is an ant macro included with the gae
sdk.
It does the same thing that dev_appserver does. The problem I'm having
is that the HelloWorld.howdy snippet is suppose to return

Log in

but it doesn't. The only thing displayed is Home

I can trace the running code to the point where S.param("login")
matches Empty,

but that's about it.

Any idea why that is happening?

Glenn...

On May 28, 1:39 pm, denew  wrote:
> I'm using maven for builds, so I can't help with your Ant process, but
> you need to start the appengine with something like:
>
> \appengine-java-sdk-1.2.1\bin\dev_appserver target\webapp-1.0-
> SNAPSHOT
>
> i.e., not just the jetty:run. I have this in a batch file in the
> webapp directory.
>
> Despite the fact I got a simple 1->M running yesterday, the story gets
> bad when I start to add other relationships to entities that already
> have them
> - this is still WIP for me
>
> On May 29, 6:17 am, glenn  wrote:
>
> > I tried to get the sample at git://github.com/ymnk/lift-gae-api.git to
> > work, but
> > couldn't. Yes, I installed all the GAE jars in my local maven
> > repository,but  launching
> > with mvn jetty:run doesn't start up the App Engine, so I get the
> > following
> > exception:
>
> > Exception occured while processing /
> > Message: java.lang.NullPointerException
> >         com.google.appengine.api.users.UserServiceImpl.getCurrentUser
> > (UserServiceImpl.java:44)
> >         foo.snippet.HelloWorld.howdy(HelloWorld.scala:13)
>
> > because there val userService = UserServiceFactory.getUserService in
> > HelloWorld is null.
>
> > So, something is missing in the process - namely - getting Lift
> > working in the App Engine. I even
> > tried a different approach.
>
> > Using the following ant build.xml:
>
> > 
> >         
> >         
> >         
>
> >         
>
> >         
> >                 
> >         
>
> >         
> >                 
> >                     
> >                   
>
> >         
>
> >          >               description="Starts the development server.">
> >                 
> >                         
> >                                 
> >                                 
> >                         
> >                 
> >         
>
> >          >               description="Uploads the application to App Engine.">
> >                 
> >         
>
> >          >               description="Uploads just the datastore index configuration to
> > App Engine.">
> >                 
> >         
>
> >          >               description="Rolls back an interrupted application update.">
> >                 
> >         
>
> >          >               description="Downloads log data from App Engine for the
> > application.">
> >                 
> >                         
> >                                 
> >                         
> >                         
> >                                 
> >                         
> >                 
> >         
>
> > 
>
> > Running the runuser target creates a war directory in the root of my
> > project, similar to
> > what the GAE Eclipse plugin creates, and starts the App Engine, but
> > nothing else.
> > The application is not accessible from the URLhttp://localhost:.
>
> > Am I doing something completely wrong, here?
>
> > Glenn...
>
> > On May 27, 2:38 pm, denew  wrote:
>
> > > Embarassingly simple really - RTFM. Within the known limitation of
> > > using Lists for the collection, not Sets, the 1->M works. Now on to
> > > the compound keys...
>
> > > On May 28, 9:01 am, denew  wrote:
>
> > > > Thanks for that Andy - I had tried using 1.1.2 and 1.1.3 and thought I
> > > > had gone back to a GAE-approved version - my mistake. I'll give that a
> > > > shot
>
> > > > On May 27, 9:11 pm, datanucleus  wrote:
>
> > > > > You're using invalid versions of DataNucleus jars (1.1.1+) with the
> > > > > GAEJ plugin for datanucleus. The current released plugin only allows
> > > > > DataNucleus 1.1.0 jars. Their next versions should allow the latest
> > > > > DataNucleus jars to be used, but you'll have to wait til they release
> > > > > it ;-)
>
> > > > > --Andy (DataNucleus)- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -

--~--~-~--~~~---~--~~
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: GAE - working example?

[glenn]

Forget that last post. I  got it working. I had template tag error
in my code.

Glenn...

On May 28, 1:39 pm, denew  wrote:
> I'm using maven for builds, so I can't help with your Ant process, but
> you need to start the appengine with something like:
>
> \appengine-java-sdk-1.2.1\bin\dev_appserver target\webapp-1.0-
> SNAPSHOT
>
> i.e., not just the jetty:run. I have this in a batch file in the
> webapp directory.
>
> Despite the fact I got a simple 1->M running yesterday, the story gets
> bad when I start to add other relationships to entities that already
> have them
> - this is still WIP for me
>
> On May 29, 6:17 am, glenn  wrote:
>
> > I tried to get the sample at git://github.com/ymnk/lift-gae-api.git to
> > work, but
> > couldn't. Yes, I installed all the GAE jars in my local maven
> > repository,but  launching
> > with mvn jetty:run doesn't start up the App Engine, so I get the
> > following
> > exception:
>
> > Exception occured while processing /
> > Message: java.lang.NullPointerException
> >         com.google.appengine.api.users.UserServiceImpl.getCurrentUser
> > (UserServiceImpl.java:44)
> >         foo.snippet.HelloWorld.howdy(HelloWorld.scala:13)
>
> > because there val userService = UserServiceFactory.getUserService in
> > HelloWorld is null.
>
> > So, something is missing in the process - namely - getting Lift
> > working in the App Engine. I even
> > tried a different approach.
>
> > Using the following ant build.xml:
>
> > 
> >         
> >         
> >         
>
> >         
>
> >         
> >                 
> >         
>
> >         
> >                 
> >                     
> >                   
>
> >         
>
> >          >               description="Starts the development server.">
> >                 
> >                         
> >                                 
> >                                 
> >                         
> >                 
> >         
>
> >          >               description="Uploads the application to App Engine.">
> >                 
> >         
>
> >          >               description="Uploads just the datastore index configuration to
> > App Engine.">
> >                 
> >         
>
> >          >               description="Rolls back an interrupted application update.">
> >                 
> >         
>
> >          >               description="Downloads log data from App Engine for the
> > application.">
> >                 
> >                         
> >                                 
> >                         
> >                         
> >                                 
> >                         
> >                 
> >         
>
> > 
>
> > Running the runuser target creates a war directory in the root of my
> > project, similar to
> > what the GAE Eclipse plugin creates, and starts the App Engine, but
> > nothing else.
> > The application is not accessible from the URLhttp://localhost:.
>
> > Am I doing something completely wrong, here?
>
> > Glenn...
>
> > On May 27, 2:38 pm, denew  wrote:
>
> > > Embarassingly simple really - RTFM. Within the known limitation of
> > > using Lists for the collection, not Sets, the 1->M works. Now on to
> > > the compound keys...
>
> > > On May 28, 9:01 am, denew  wrote:
>
> > > > Thanks for that Andy - I had tried using 1.1.2 and 1.1.3 and thought I
> > > > had gone back to a GAE-approved version - my mistake. I'll give that a
> > > > shot
>
> > > > On May 27, 9:11 pm, datanucleus  wrote:
>
> > > > > You're using invalid versions of DataNucleus jars (1.1.1+) with the
> > > > > GAEJ plugin for datanucleus. The current released plugin only allows
> > > > > DataNucleus 1.1.0 jars. Their next versions should allow the latest
> > > > > DataNucleus jars to be used, but you'll have to wait til they release
> > > > > it ;-)
>
> > > > > --Andy (DataNucleus)- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -

--~--~-~--~~~---~--~~
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] Dependent fields in form

[feelgood]

Is it real to create form with dependent field? Suppose whe have two
select boxes: for the country and for the city. It would be quite
good, if country selection trigger updating of the cities list.

--~--~-~--~~~---~--~~
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: JTA

[Meredith Gregory]

Jonas,

i applaud the effort. i agree with DPP sentiments regarding annotations.
That said, i feel pretty comfortable that transactions fit entirely in a
monadic context. Since LINQ demonstrates that query fits into monadic
context, and there's already at least one Scala implementation of
LINQ,
might i suggest that you come up with a monadic presentation first and then
map the sugar to that. My guess is that the sugar will be informed by the
monadic presentation.

To be suggestive... think of a context with a Tx object, TxCtxt, as like an
Option widget. Then you do stuff inside a transaction via

for ( myTransactedWidget <- TxCtxt if  ) yield {
 }

If you implement flatMap, yada, on TxCtxt you can have fun with nested
transaction semantics. The point is that this should just work with a
LINQ-like presentation of query.

Best wishes,

--greg

On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrote:

>
> I'll go for closures. Much simpler and less intrusive into Lift.
> The current impl is based on Atomikos and Hibernate, I'll start with
> pushing that in and we can make it pluggable later.
> For example for Hibernate one need to add a line to the hibernate
> config to register the
> org.hibernate.transaction.TransactionManagerLookup class in order to
> make Hibernate aware of our TX manager.
>
> Should I fork the github repo and submit patches or how do you guys work?
>
> /Jonas
>
>
> 2009/5/29 Derek Chen-Becker :
> > I'd vote for closures. We use annotations for JPA because we have to, but
> > IMHO closures provide a nicer semantic approach because they
> syntactically
> > enclose the block where the action is occurring.
> >
> > Derek
> >
> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
> >>
> >> No perf difference. The annotations are turned into the same exact
> >> closures.
> >>
> >> 2009/5/29 Timothy Perrett :
> >> >
> >> >
> >> > Are there any performance implications considering closures vs
> >> > annotations?
> >> > Agreed that closures are more "lift like" however.
> >> >
> >> > Cheers, Tim
> >> >
> >> > On 29/05/2009 10:21, "marius d."  wrote:
> >> >
> >> >>
> >> >> I think that would be really good. But I'd rather not use
> annotations.
> >> >> Personally I find closures approach a much better fit here.
> >> >>
> >> >> withTxRequired {
> >> >>   ... // do transational stuff
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >> Br's,
> >> >> Marius
> >> >>
> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
> >> >>> Hi guys.
> >> >>>
> >> >>> I have been talking with David Pollak the rest of the lift team
> about
> >> >>> adding JTA to Lift. I have implemented that for a product written in
> >> >>> Scala some time ago. Now some of that code is OSS
> >> >>> at:http://github.com/jboner/skalman/tree
> >> >>>
> >> >>> We used using two different APIs.
> >> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
> >> >>> grab them from a factory):
> >> >>>
> >> >>> @TransactionAttribute(REQUIRED)
> >> >>> def transactionalMethod = { ... }
> >> >>>
> >> >>> 2. Call-by-name:
> >> >>>
> >> >>> withTxRequired {
> >> >>>   ... // do transational stuff
> >> >>>
> >> >>> }
> >> >>>
> >> >>> But I don't know what fits Lift and would like to know how you guys
> >> >>> would like to have JTA integrated.
> >> >>> At which level? Which APIs? Etc.
> >> >>>
> >> >>> --
> >> >>> Jonas Bonér
> >> >>>
> >> >>> twitter: @jboner
> >> >>> blog:http://jonasboner.com
> >> >>> work:  http://crisp.se
> >> >>> work:  http://scalablesolutions.se
> >> >>> code:  http://github.com/jboner
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Jonas Bonér
> >>
> >> twitter: @jboner
> >> blog:http://jonasboner.com
> >> work:   http://crisp.se
> >> work:   http://scalablesolutions.se
> >> code:   http://github.com/jboner
> >>
> >>
> >
> >
> > >
> >
>
>
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog:http://jonasboner.com
> work:   http://crisp.se
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
>
> >
>


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--~--~-~--~~~---~--~~
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] LiftOff

[Meredith Gregory]

David,

i didn't realize the LiftOff conflicted with a long-planned participation in
a Guitar Craft course. i will definitely send good will and good wishes to
the community. i'm certain you guys will have much too much fun. Maybe i can
organize some kind of functional-computing-and-the-web event in the Pacific
Northwest in the not too distant future, so that i can catch up with
everybody.

Best wishes,

--greg

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--~--~-~--~~~---~--~~
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: JTA

[Timothy Perrett]

Wow, that I would very much like to see... using for comprehensions  
for transactions!

Cheers, Tim

Sent from my iPhone

On 29 May 2009, at 23:54, Meredith Gregory   
wrote:

> Jonas,
>
> i applaud the effort. i agree with DPP sentiments regarding  
> annotations. That said, i feel pretty comfortable that transactions  
> fit entirely in a monadic context. Since LINQ demonstrates that  
> query fits into monadic context, and there's already at least one  
> Scala implementation of LINQ, might i suggest that you come up with  
> a monadic presentation first and then map the sugar to that. My  
> guess is that the sugar will be informed by the monadic presentation.
>
> To be suggestive... think of a context with a Tx object, TxCtxt, as  
> like an Option widget. Then you do stuff inside a transaction via
>
> for ( myTransactedWidget <- TxCtxt if  ) yield  
> {  }
>
> If you implement flatMap, yada, on TxCtxt you can have fun with  
> nested transaction semantics. The point is that this should just  
> work with a LINQ-like presentation of query.
>
> Best wishes,
>
> --greg
>
> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrot 
> e:
>
> I'll go for closures. Much simpler and less intrusive into Lift.
> The current impl is based on Atomikos and Hibernate, I'll start with
> pushing that in and we can make it pluggable later.
> For example for Hibernate one need to add a line to the hibernate
> config to register the
> org.hibernate.transaction.TransactionManagerLookup class in order to
> make Hibernate aware of our TX manager.
>
> Should I fork the github repo and submit patches or how do you guys  
> work?
>
> /Jonas
>
>
> 2009/5/29 Derek Chen-Becker :
> > I'd vote for closures. We use annotations for JPA because we have  
> to, but
> > IMHO closures provide a nicer semantic approach because they  
> syntactically
> > enclose the block where the action is occurring.
> >
> > Derek
> >
> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wr 
> ote:
> >>
> >> No perf difference. The annotations are turned into the same exact
> >> closures.
> >>
> >> 2009/5/29 Timothy Perrett :
> >> >
> >> >
> >> > Are there any performance implications considering closures vs
> >> > annotations?
> >> > Agreed that closures are more "lift like" however.
> >> >
> >> > Cheers, Tim
> >> >
> >> > On 29/05/2009 10:21, "marius d."  wrote:
> >> >
> >> >>
> >> >> I think that would be really good. But I'd rather not use  
> annotations.
> >> >> Personally I find closures approach a much better fit here.
> >> >>
> >> >> withTxRequired {
> >> >>   ... // do transational stuff
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >> Br's,
> >> >> Marius
> >> >>
> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
> >> >>> Hi guys.
> >> >>>
> >> >>> I have been talking with David Pollak the rest of the lift  
> team about
> >> >>> adding JTA to Lift. I have implemented that for a product  
> written in
> >> >>> Scala some time ago. Now some of that code is OSS
> >> >>> at:http://github.com/jboner/skalman/tree
> >> >>>
> >> >>> We used using two different APIs.
> >> >>> 1. Annotations (would require Lift to support proxied  
> objects, e.g.
> >> >>> grab them from a factory):
> >> >>>
> >> >>> @TransactionAttribute(REQUIRED)
> >> >>> def transactionalMethod = { ... }
> >> >>>
> >> >>> 2. Call-by-name:
> >> >>>
> >> >>> withTxRequired {
> >> >>>   ... // do transational stuff
> >> >>>
> >> >>> }
> >> >>>
> >> >>> But I don't know what fits Lift and would like to know how  
> you guys
> >> >>> would like to have JTA integrated.
> >> >>> At which level? Which APIs? Etc.
> >> >>>
> >> >>> --
> >> >>> Jonas Bonér
> >> >>>
> >> >>> twitter: @jboner
> >> >>> blog:http://jonasboner.com
> >> >>> work:  http://crisp.se
> >> >>> work:  http://scalablesolutions.se
> >> >>> code:  http://github.com/jboner
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Jonas Bonér
> >>
> >> twitter: @jboner
> >> blog:http://jonasboner.com
> >> work:   http://crisp.se
> >> work:   http://scalablesolutions.se
> >> code:   http://github.com/jboner
> >>
> >>
> >
> >
> > >
> >
>
>
>
> --
> Jonas Bonér
>
> twitter: @jboner
> blog:http://jonasboner.com
> work:   http://crisp.se
> work:   http://scalablesolutions.se
> code:   http://github.com/jboner
>
>
>
>
>
> -- 
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
> >

--~--~-~--~~~---~--~~
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: How important is AJAX to you?

[Meredith Gregory]

Joe,

i love questions like this: 'what are the real requirements?'

i have no particular interest in technology like AJAX -- except as a means
to an end. i need to be able to build sites that are the web's equivalent of
CSCW apps from the late 80s/early 90s. In the web apps i'm working on users
have an experience of sharing a common space to design and edit complex
computational models and large, rich data sets.

One can imagine all sorts of technologies to do this on the existing web
infrastructure. The real issue is not having to reinvent a bunch of stuff in
order to remain focused on the very hard problems of providing the stuff
above. AJAX took off. That fact that it got embodied in a bunch of
unmaintainable crap like JavaScript -- well i'll ride that wave for a while.


Frameworks like Lift can alleviate some of the problem, but you really need
a good, statically typed language on the client side. A few people are
beginning to take this problem on. It'd be great to see a ScalaScript for
rich client-side experiences.

Best wishes,

--greg

On Fri, May 29, 2009 at 10:36 AM, Charles F. Munat  wrote:

>
> Lift makes AJAX easy, but Lift has nothing to do with AJAX. Lift makes a
> lot of things easy.
>
> I've built half a dozen sites in Lift so far, with several more in the
> works, and most of them use no AJAX at all.
>
> That said, there is a lot to be said for AJAX when used properly. I
> think you're way off on that. The problem is (as with pretty much
> everything else on the Web), it's rarely used properly. Google does it
> mostly right. Facebook is mostly a mess.
>
> Chas.
>
> Joe Wass wrote:
> > This may be heresy on this list, but I'll ask it anyway. A general
> > point for discussion which I'm raising because the Lift Book mentions
> > AJAX early on in the PocketChange app.
> >
> > How important is AJAX and all the associated Web 2.0 stuff to you and
> > to your projects? I'm quite happy without Javascript and AJAX. More
> > often than not they're doing the kind of thing you could just as
> > easily do with traditional technologies. Save for one web-app (Google
> > Mail), I don't think a single site I use has been improved for it.
> > Particular examples are Slashdot and Facebook. Give me good old HTML
> > any day.
> >
> > I've got a few projects in the pipeline and I intend to use Lift for
> > all of them, it looks excellent and from the source I've read very
> > nicely engineered. But I will expressly avoid using anything other
> > than old-fashioned HTML as much as I can, largely because I'm
> > targetting browsers of unknown vintage in less economically developed
> > countries and I'd like to be able to use my own site without cookies
> > or javascript if I want to.
> >
> > Have I missed the point of Lift entirely? Am I in a small minority? Am
> > I crazy?
> >
> > Joe
> >
> > >
>
> >
>


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--~--~-~--~~~---~--~~
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: JTA

[Jorge Ortiz]

I, too, would like to see Transactions be monadic.

--j

On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
wrote:

> Jonas,
>
> i applaud the effort. i agree with DPP sentiments regarding annotations.
> That said, i feel pretty comfortable that transactions fit entirely in a
> monadic context. Since LINQ demonstrates that query fits into monadic
> context, and there's already at least one Scala implementation of 
> LINQ,
> might i suggest that you come up with a monadic presentation first and then
> map the sugar to that. My guess is that the sugar will be informed by the
> monadic presentation.
>
> To be suggestive... think of a context with a Tx object, TxCtxt, as like an
> Option widget. Then you do stuff inside a transaction via
>
> for ( myTransactedWidget <- TxCtxt if  ) yield {
>  }
>
> If you implement flatMap, yada, on TxCtxt you can have fun with nested
> transaction semantics. The point is that this should just work with a
> LINQ-like presentation of query.
>
> Best wishes,
>
> --greg
>
>
> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrote:
>
>>
>> I'll go for closures. Much simpler and less intrusive into Lift.
>> The current impl is based on Atomikos and Hibernate, I'll start with
>> pushing that in and we can make it pluggable later.
>> For example for Hibernate one need to add a line to the hibernate
>> config to register the
>> org.hibernate.transaction.TransactionManagerLookup class in order to
>> make Hibernate aware of our TX manager.
>>
>> Should I fork the github repo and submit patches or how do you guys work?
>>
>> /Jonas
>>
>>
>> 2009/5/29 Derek Chen-Becker :
>> > I'd vote for closures. We use annotations for JPA because we have to,
>> but
>> > IMHO closures provide a nicer semantic approach because they
>> syntactically
>> > enclose the block where the action is occurring.
>> >
>> > Derek
>> >
>> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>> >>
>> >> No perf difference. The annotations are turned into the same exact
>> >> closures.
>> >>
>> >> 2009/5/29 Timothy Perrett :
>> >> >
>> >> >
>> >> > Are there any performance implications considering closures vs
>> >> > annotations?
>> >> > Agreed that closures are more "lift like" however.
>> >> >
>> >> > Cheers, Tim
>> >> >
>> >> > On 29/05/2009 10:21, "marius d."  wrote:
>> >> >
>> >> >>
>> >> >> I think that would be really good. But I'd rather not use
>> annotations.
>> >> >> Personally I find closures approach a much better fit here.
>> >> >>
>> >> >> withTxRequired {
>> >> >>   ... // do transational stuff
>> >> >>
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Br's,
>> >> >> Marius
>> >> >>
>> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
>> >> >>> Hi guys.
>> >> >>>
>> >> >>> I have been talking with David Pollak the rest of the lift team
>> about
>> >> >>> adding JTA to Lift. I have implemented that for a product written
>> in
>> >> >>> Scala some time ago. Now some of that code is OSS
>> >> >>> at:http://github.com/jboner/skalman/tree
>> >> >>>
>> >> >>> We used using two different APIs.
>> >> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> >> >>> grab them from a factory):
>> >> >>>
>> >> >>> @TransactionAttribute(REQUIRED)
>> >> >>> def transactionalMethod = { ... }
>> >> >>>
>> >> >>> 2. Call-by-name:
>> >> >>>
>> >> >>> withTxRequired {
>> >> >>>   ... // do transational stuff
>> >> >>>
>> >> >>> }
>> >> >>>
>> >> >>> But I don't know what fits Lift and would like to know how you guys
>> >> >>> would like to have JTA integrated.
>> >> >>> At which level? Which APIs? Etc.
>> >> >>>
>> >> >>> --
>> >> >>> Jonas Bonér
>> >> >>>
>> >> >>> twitter: @jboner
>> >> >>> blog:http://jonasboner.com
>> >> >>> work:  http://crisp.se
>> >> >>> work:  http://scalablesolutions.se
>> >> >>> code:  http://github.com/jboner
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Jonas Bonér
>> >>
>> >> twitter: @jboner
>> >> blog:http://jonasboner.com
>> >> work:   http://crisp.se
>> >> work:   http://scalablesolutions.se
>> >> code:   http://github.com/jboner
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>
>
> >
>

--~--~-~--~~~---~--~~
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: LiftOff

[Charles F. Munat]

Rats.

Meredith Gregory wrote:
> David,
> 
> i didn't realize the LiftOff conflicted with a long-planned 
> participation in a Guitar Craft course. i will definitely send good will 
> and good wishes to the community. i'm certain you guys will have much 
> too much fun. Maybe i can organize some kind of 
> functional-computing-and-the-web event in the Pacific Northwest in the 
> not too distant future, so that i can catch up with everybody.
> 
> Best wishes,
> 
> --greg
> 
> -- 
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
> 
> +1 206.650.3740
> 
> http://biosimilarity.blogspot.com
> 
> > 

--~--~-~--~~~---~--~~
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: JTA

[Josh Suereth]

+30

So many pluses in fact, that we are already experimenting with this concept
at work.  Unfortunately, the source may not be "openable".  I'd be more than
willing to contribute to an open-source JTA monadic library.

for( tx <- context) {
   //Do stuff
   if(somethingBad) tx.rollback()
   //Do more stuff
}

Just seems to fit the needs of my software *much* better than the magical
annotated method...errr... method seen in EJB and Spring.


-Josh

On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz  wrote:

> I, too, would like to see Transactions be monadic.
>
> --j
>
>
> On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> Jonas,
>>
>> i applaud the effort. i agree with DPP sentiments regarding annotations.
>> That said, i feel pretty comfortable that transactions fit entirely in a
>> monadic context. Since LINQ demonstrates that query fits into monadic
>> context, and there's already at least one Scala implementation of 
>> LINQ,
>> might i suggest that you come up with a monadic presentation first and then
>> map the sugar to that. My guess is that the sugar will be informed by the
>> monadic presentation.
>>
>> To be suggestive... think of a context with a Tx object, TxCtxt, as like
>> an Option widget. Then you do stuff inside a transaction via
>>
>> for ( myTransactedWidget <- TxCtxt if  ) yield {
>>  }
>>
>> If you implement flatMap, yada, on TxCtxt you can have fun with nested
>> transaction semantics. The point is that this should just work with a
>> LINQ-like presentation of query.
>>
>> Best wishes,
>>
>> --greg
>>
>>
>> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrote:
>>
>>>
>>> I'll go for closures. Much simpler and less intrusive into Lift.
>>> The current impl is based on Atomikos and Hibernate, I'll start with
>>> pushing that in and we can make it pluggable later.
>>> For example for Hibernate one need to add a line to the hibernate
>>> config to register the
>>> org.hibernate.transaction.TransactionManagerLookup class in order to
>>> make Hibernate aware of our TX manager.
>>>
>>> Should I fork the github repo and submit patches or how do you guys work?
>>>
>>> /Jonas
>>>
>>>
>>> 2009/5/29 Derek Chen-Becker :
>>> > I'd vote for closures. We use annotations for JPA because we have to,
>>> but
>>> > IMHO closures provide a nicer semantic approach because they
>>> syntactically
>>> > enclose the block where the action is occurring.
>>> >
>>> > Derek
>>> >
>>> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>>> >>
>>> >> No perf difference. The annotations are turned into the same exact
>>> >> closures.
>>> >>
>>> >> 2009/5/29 Timothy Perrett :
>>> >> >
>>> >> >
>>> >> > Are there any performance implications considering closures vs
>>> >> > annotations?
>>> >> > Agreed that closures are more "lift like" however.
>>> >> >
>>> >> > Cheers, Tim
>>> >> >
>>> >> > On 29/05/2009 10:21, "marius d."  wrote:
>>> >> >
>>> >> >>
>>> >> >> I think that would be really good. But I'd rather not use
>>> annotations.
>>> >> >> Personally I find closures approach a much better fit here.
>>> >> >>
>>> >> >> withTxRequired {
>>> >> >>   ... // do transational stuff
>>> >> >>
>>> >> >> }
>>> >> >>
>>> >> >>
>>> >> >> Br's,
>>> >> >> Marius
>>> >> >>
>>> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
>>> >> >>> Hi guys.
>>> >> >>>
>>> >> >>> I have been talking with David Pollak the rest of the lift team
>>> about
>>> >> >>> adding JTA to Lift. I have implemented that for a product written
>>> in
>>> >> >>> Scala some time ago. Now some of that code is OSS
>>> >> >>> at:http://github.com/jboner/skalman/tree
>>> >> >>>
>>> >> >>> We used using two different APIs.
>>> >> >>> 1. Annotations (would require Lift to support proxied objects,
>>> e.g.
>>> >> >>> grab them from a factory):
>>> >> >>>
>>> >> >>> @TransactionAttribute(REQUIRED)
>>> >> >>> def transactionalMethod = { ... }
>>> >> >>>
>>> >> >>> 2. Call-by-name:
>>> >> >>>
>>> >> >>> withTxRequired {
>>> >> >>>   ... // do transational stuff
>>> >> >>>
>>> >> >>> }
>>> >> >>>
>>> >> >>> But I don't know what fits Lift and would like to know how you
>>> guys
>>> >> >>> would like to have JTA integrated.
>>> >> >>> At which level? Which APIs? Etc.
>>> >> >>>
>>> >> >>> --
>>> >> >>> Jonas Bonér
>>> >> >>>
>>> >> >>> twitter: @jboner
>>> >> >>> blog:http://jonasboner.com
>>> >> >>> work:  http://crisp.se
>>> >> >>> work:  http://scalablesolutions.se
>>> >> >>> code:  http://github.com/jboner
>>> >> >> >
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jonas Bonér
>>> >>
>>> >> twitter: @jboner
>>> >> blog:http://jonasboner.com
>>> >> work:   http://crisp.se
>>> >> work:   http://scalablesolutions.se
>>> >> code:   http://github.com/jboner
>>> >>
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Jonas Bonér
>>>
>>> twitter: @jboner
>>> blog:http://jonasboner.com
>>> work:   http://crisp.se

[Lift] Re: JTA

[David Pollak]

On Fri, May 29, 2009 at 7:19 PM, Josh Suereth wrote:

> +30


See http://github.com/dpp/goatrodeo/tree/master

>
>
> So many pluses in fact, that we are already experimenting with this concept
> at work.  Unfortunately, the source may not be "openable".  I'd be more than
> willing to contribute to an open-source JTA monadic library.
>
> for( tx <- context) {
>//Do stuff
>if(somethingBad) tx.rollback()
>//Do more stuff
> }
>
> Just seems to fit the needs of my software *much* better than the magical
> annotated method...errr... method seen in EJB and Spring.
>
>
> -Josh
>
>
> On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz wrote:
>
>> I, too, would like to see Transactions be monadic.
>>
>> --j
>>
>>
>> On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory <
>> lgreg.mered...@gmail.com> wrote:
>>
>>> Jonas,
>>>
>>> i applaud the effort. i agree with DPP sentiments regarding annotations.
>>> That said, i feel pretty comfortable that transactions fit entirely in a
>>> monadic context. Since LINQ demonstrates that query fits into monadic
>>> context, and there's already at least one Scala implementation of 
>>> LINQ,
>>> might i suggest that you come up with a monadic presentation first and then
>>> map the sugar to that. My guess is that the sugar will be informed by the
>>> monadic presentation.
>>>
>>> To be suggestive... think of a context with a Tx object, TxCtxt, as like
>>> an Option widget. Then you do stuff inside a transaction via
>>>
>>> for ( myTransactedWidget <- TxCtxt if  ) yield {
>>>  }
>>>
>>> If you implement flatMap, yada, on TxCtxt you can have fun with nested
>>> transaction semantics. The point is that this should just work with a
>>> LINQ-like presentation of query.
>>>
>>> Best wishes,
>>>
>>> --greg
>>>
>>>
>>> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrote:
>>>

 I'll go for closures. Much simpler and less intrusive into Lift.
 The current impl is based on Atomikos and Hibernate, I'll start with
 pushing that in and we can make it pluggable later.
 For example for Hibernate one need to add a line to the hibernate
 config to register the
 org.hibernate.transaction.TransactionManagerLookup class in order to
 make Hibernate aware of our TX manager.

 Should I fork the github repo and submit patches or how do you guys
 work?

 /Jonas


 2009/5/29 Derek Chen-Becker :
 > I'd vote for closures. We use annotations for JPA because we have to,
 but
 > IMHO closures provide a nicer semantic approach because they
 syntactically
 > enclose the block where the action is occurring.
 >
 > Derek
 >
 > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér 
 wrote:
 >>
 >> No perf difference. The annotations are turned into the same exact
 >> closures.
 >>
 >> 2009/5/29 Timothy Perrett :
 >> >
 >> >
 >> > Are there any performance implications considering closures vs
 >> > annotations?
 >> > Agreed that closures are more "lift like" however.
 >> >
 >> > Cheers, Tim
 >> >
 >> > On 29/05/2009 10:21, "marius d."  wrote:
 >> >
 >> >>
 >> >> I think that would be really good. But I'd rather not use
 annotations.
 >> >> Personally I find closures approach a much better fit here.
 >> >>
 >> >> withTxRequired {
 >> >>   ... // do transational stuff
 >> >>
 >> >> }
 >> >>
 >> >>
 >> >> Br's,
 >> >> Marius
 >> >>
 >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
 >> >>> Hi guys.
 >> >>>
 >> >>> I have been talking with David Pollak the rest of the lift team
 about
 >> >>> adding JTA to Lift. I have implemented that for a product written
 in
 >> >>> Scala some time ago. Now some of that code is OSS
 >> >>> at:http://github.com/jboner/skalman/tree
 >> >>>
 >> >>> We used using two different APIs.
 >> >>> 1. Annotations (would require Lift to support proxied objects,
 e.g.
 >> >>> grab them from a factory):
 >> >>>
 >> >>> @TransactionAttribute(REQUIRED)
 >> >>> def transactionalMethod = { ... }
 >> >>>
 >> >>> 2. Call-by-name:
 >> >>>
 >> >>> withTxRequired {
 >> >>>   ... // do transational stuff
 >> >>>
 >> >>> }
 >> >>>
 >> >>> But I don't know what fits Lift and would like to know how you
 guys
 >> >>> would like to have JTA integrated.
 >> >>> At which level? Which APIs? Etc.
 >> >>>
 >> >>> --
 >> >>> Jonas Bonér
 >> >>>
 >> >>> twitter: @jboner
 >> >>> blog:http://jonasboner.com
 >> >>> work:  http://crisp.se
 >> >>> work:  http://scalablesolutions.se
 >> >>> code:  http://github.com/jboner
 >> >> >
 >> >>
 >> >
 >> >
 >> >
 >> > >
 >> >
 >>
 >>
 >>
 >> --
 >> Jonas Bonér
 >>
 >> twitter: @jboner
 >> blog:http:

[Lift] Re: Dependent fields in form

[marius d.]

That should be quite easy. See http://demo.liftweb.net/ajax-form


Marius

On May 29, 9:46 pm, feelgood  wrote:
> Is it real to create form with dependent field? Suppose whe have two
> select boxes: for the country and for the city. It would be quite
> good, if country selection trigger updating of the cities list.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---