[Lift] Re: [Lift committers] Re: Meeting

[David Pollak]

Lee,

The reason that Lift has the richer MappedField and Field objects in Mapper
and Record is to programmatically add this kind of functionality to fields.
No, it's not PoJos, but it's as syntactically clean and a lot easier to
understand/debug.

Thanks,

David

On Fri, Apr 17, 2009 at 9:47 AM, Lee Mighdoll  wrote:

> I'm currently giving AOP a try 
> here(not in lift).   I was 
> looking for a cleaner way to create objects with
> observable properties.  I like that an aspect allows for observable objects
> that are idiomatic to use and write, and don't require any extra
> boilerplate.
>
>
> The scala class needs only to add the marker trait Observable.
>
>   class Model extends Observable {
> var prop:String = _
>   }
>
> Modifications to the instance will then trigger the aspect, notifying an 
> observer.
>
> val model = new Model()
> m.prop = "whee"
>
> Run that and the test observer sees the change and prints:
>
> change observed> example.mo...@6abf2d5e=>> prop:whee
>
>
> I'm getting more tempted to use aspectJ because it enables such a simple and 
> idiomatic
>
> approach to writing model objects that are:
> * Concise to write
> * Use the normal idioms for working with mutable scala objects.
> * Compatible with java libraries, including JPA...
>
>
> The sources are in src.
>
> To try it yourself, use this script which runs mvn.
> ./tryMe
>
>
>
>
>
>
>
>
>
> On Fri, Apr 17, 2009 at 4:26 AM, Josh Suereth wrote:
>
>>
>>>
>>> You can impl AOP using many different techniques. I proposed the
>>> simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
>>> Proxy (which is the 'build in Java reflect proxy thingy'). What is
>>> your question?
>>>
>>> >> >
>>> >> > So, what does AOP give us that can't be done at another phase?
>>>
>>> AOP is not about a specific phase. It can be done at:
>>> * compile time
>>> * class load time
>>> * runtime
>>>
>>> Can be done with:
>>> * Bytecode mods
>>> * Generated proxy
>>> * Dynamic proxy
>>> * JVM-level hooks
>>>
>>> >> >
>>> >>
>>> >> Semantics to annotations.
>>> >
>>> > Can you help out with an example?
>>>
>>> Annotate a class with f.e.
>>> @transactional(type=Required)  class Foo { ..}
>>> and have all methods in this class being invoked under a transaction
>>> with Required semantics
>>>
>>> or annotate a specific method
>>> @transactional(type=RequiresNew)  def foo { ..}
>>> to get the same behavior for a method only
>>>
>>> Annotations is the way most JEE devs are used to handle these things
>>> since it is the approach both Spring, Guice, EJB 3 etc. etc. has
>>> taken.
>>>
>>
>>
>> I use this all the time in java, because there is no other "good" option
>> for transactions in java.  It's basically the best method.  However I don't
>> believe this is the case in Scala, and I'd rather think through the options
>> and determine the best one.
>>
>>
>>
>>>
>>> The stuff I have written allow using AspectJ pointcuts as well.
>>> E.g. f.e. apply transactions to all methods in the service layer:
>>> match('* com.biz.service.*(..)')
>>>
>>> Or to a specific method:
>>> match('void Store.buy(Item)')
>>>
>>
>>
>> Point-cuts after-the fact seem a decent use of transactions.  This is
>> under the following assumptions:
>>
>> 1) Your code will be used in more than one configuration type
>> 2) Your transaction granularity is determined by the configuration of your
>> "module", not by the module itself.
>>
>> Regarding 2, I think all-to-often real world problems begin to break this
>> assumption, making internal business logic and external transaction
>> configuration dependent on each other.
>>
>>
>>>
>>> But you could just use call-by-name:
>>>
>>> transactional(TransactionType.Required) { // tx begin
>>>  .. // do stuff in TX
>>> }  // tx commit or rollback
>>>
>>> But that pollutes the code, makes it harder to change, configure and
>>> is not declarative.
>>> Perhaps give the user options?
>>>
>>
>> How is it not declarative?  I agree that Aspects really do give you better
>> configuration abilities for code, however I'm not sure transactions are
>> ideally suited for AOP.  I think Java is not ideally suited for
>> transactional code, so we use AOP.
>>
>>
>>
>>
>> I'd love to hear your response!  This is something I've been mulling
>> through recently, and I'm still on the fence for "Transactions should be
>> done using AOP on the JVM"
>>
>> -Josh
>>
>>
>>
>>
>
> >
>


-- 
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://group

[Lift] Re: [Lift committers] Re: Meeting

[Lee Mighdoll]

I'm currently giving AOP a try
here(not in lift).
I was looking for a cleaner way to create objects with
observable properties.  I like that an aspect allows for observable objects
that are idiomatic to use and write, and don't require any extra
boilerplate.


The scala class needs only to add the marker trait Observable.

  class Model extends Observable {
var prop:String = _
  }

Modifications to the instance will then trigger the aspect, notifying
an observer.

val model = new Model()
m.prop = "whee"

Run that and the test observer sees the change and prints:

change observed> example.mo...@6abf2d5e=>> prop:whee


I'm getting more tempted to use aspectJ because it enables such a
simple and idiomatic
approach to writing model objects that are:
* Concise to write
* Use the normal idioms for working with mutable scala objects.
* Compatible with java libraries, including JPA...


The sources are in src.

To try it yourself, use this script which runs mvn.
./tryMe









On Fri, Apr 17, 2009 at 4:26 AM, Josh Suereth wrote:

>
>>
>> You can impl AOP using many different techniques. I proposed the
>> simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
>> Proxy (which is the 'build in Java reflect proxy thingy'). What is
>> your question?
>>
>> >> >
>> >> > So, what does AOP give us that can't be done at another phase?
>>
>> AOP is not about a specific phase. It can be done at:
>> * compile time
>> * class load time
>> * runtime
>>
>> Can be done with:
>> * Bytecode mods
>> * Generated proxy
>> * Dynamic proxy
>> * JVM-level hooks
>>
>> >> >
>> >>
>> >> Semantics to annotations.
>> >
>> > Can you help out with an example?
>>
>> Annotate a class with f.e.
>> @transactional(type=Required)  class Foo { ..}
>> and have all methods in this class being invoked under a transaction
>> with Required semantics
>>
>> or annotate a specific method
>> @transactional(type=RequiresNew)  def foo { ..}
>> to get the same behavior for a method only
>>
>> Annotations is the way most JEE devs are used to handle these things
>> since it is the approach both Spring, Guice, EJB 3 etc. etc. has
>> taken.
>>
>
>
> I use this all the time in java, because there is no other "good" option
> for transactions in java.  It's basically the best method.  However I don't
> believe this is the case in Scala, and I'd rather think through the options
> and determine the best one.
>
>
>
>>
>> The stuff I have written allow using AspectJ pointcuts as well.
>> E.g. f.e. apply transactions to all methods in the service layer:
>> match('* com.biz.service.*(..)')
>>
>> Or to a specific method:
>> match('void Store.buy(Item)')
>>
>
>
> Point-cuts after-the fact seem a decent use of transactions.  This is under
> the following assumptions:
>
> 1) Your code will be used in more than one configuration type
> 2) Your transaction granularity is determined by the configuration of your
> "module", not by the module itself.
>
> Regarding 2, I think all-to-often real world problems begin to break this
> assumption, making internal business logic and external transaction
> configuration dependent on each other.
>
>
>>
>> But you could just use call-by-name:
>>
>> transactional(TransactionType.Required) { // tx begin
>>  .. // do stuff in TX
>> }  // tx commit or rollback
>>
>> But that pollutes the code, makes it harder to change, configure and
>> is not declarative.
>> Perhaps give the user options?
>>
>
> How is it not declarative?  I agree that Aspects really do give you better
> configuration abilities for code, however I'm not sure transactions are
> ideally suited for AOP.  I think Java is not ideally suited for
> transactional code, so we use AOP.
>
>
>
>
> I'd love to hear your response!  This is something I've been mulling
> through recently, and I'm still on the fence for "Transactions should be
> done using AOP on the JVM"
>
> -Josh
>
>
> >
>

--~--~-~--~~~---~--~~
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: [Lift committers] Re: Meeting

[Josh Suereth]

>
>
>
> You can impl AOP using many different techniques. I proposed the
> simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
> Proxy (which is the 'build in Java reflect proxy thingy'). What is
> your question?
>
> >> >
> >> > So, what does AOP give us that can't be done at another phase?
>
> AOP is not about a specific phase. It can be done at:
> * compile time
> * class load time
> * runtime
>
> Can be done with:
> * Bytecode mods
> * Generated proxy
> * Dynamic proxy
> * JVM-level hooks
>
> >> >
> >>
> >> Semantics to annotations.
> >
> > Can you help out with an example?
>
> Annotate a class with f.e.
> @transactional(type=Required)  class Foo { ..}
> and have all methods in this class being invoked under a transaction
> with Required semantics
>
> or annotate a specific method
> @transactional(type=RequiresNew)  def foo { ..}
> to get the same behavior for a method only
>
> Annotations is the way most JEE devs are used to handle these things
> since it is the approach both Spring, Guice, EJB 3 etc. etc. has
> taken.
>


I use this all the time in java, because there is no other "good" option for
transactions in java.  It's basically the best method.  However I don't
believe this is the case in Scala, and I'd rather think through the options
and determine the best one.



>
> The stuff I have written allow using AspectJ pointcuts as well.
> E.g. f.e. apply transactions to all methods in the service layer:
> match('* com.biz.service.*(..)')
>
> Or to a specific method:
> match('void Store.buy(Item)')
>


Point-cuts after-the fact seem a decent use of transactions.  This is under
the following assumptions:

1) Your code will be used in more than one configuration type
2) Your transaction granularity is determined by the configuration of your
"module", not by the module itself.

Regarding 2, I think all-to-often real world problems begin to break this
assumption, making internal business logic and external transaction
configuration dependent on each other.


>
> But you could just use call-by-name:
>
> transactional(TransactionType.Required) { // tx begin
>  .. // do stuff in TX
> }  // tx commit or rollback
>
> But that pollutes the code, makes it harder to change, configure and
> is not declarative.
> Perhaps give the user options?
>

How is it not declarative?  I agree that Aspects really do give you better
configuration abilities for code, however I'm not sure transactions are
ideally suited for AOP.  I think Java is not ideally suited for
transactional code, so we use AOP.




I'd love to hear your response!  This is something I've been mulling through
recently, and I'm still on the fence for "Transactions should be done using
AOP on the JVM"

-Josh

--~--~-~--~~~---~--~~
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: [Lift committers] Re: Meeting

[Jonas Bonér]

2009/4/16 David Pollak :
> Taking the discussion to the main list
>
> On Thu, Apr 16, 2009 at 10:23 AM, Jonas Bonér  wrote:
>>
>> 2009/4/16 David Pollak :
>> >
>> >
>> > On Thu, Apr 16, 2009 at 7:08 AM, Jonas Bonér 
>> > wrote:
>> >>
>> >> 2009/4/16 David Pollak :
>> >> > It'd be optimal if you could discuss the JTA stuff in the public
>> >> > forum.
>> >> >  In
>> >> > terms of AOP, I'm really not kidding that AOP is not going to happen
>> >> > in
>> >> > Lift.
>> >>
>> >> You don't like annotations? E.g. @Transactional etc.?
>> >
>> > I'm not keen on annotations, but I can live with them.
>> >
>> > I am firmly against anything that re-writes byte-code after the
>> > compilation
>> > phase for production code.  Once the Scala-Maven plugin supports
>> > compiler
>> > plugins, then there's a lot of stuff that can be done at compile-time.
>>
>> The AOP stuff I have done is based on dynamic proxies no bytecode munging.
>
> OKay... I need to see some example to fully understand why a proxy needs AOP
> rather than either (1) compile-time proxy generation or (2) the built-in
> Java reflect proxy thingy.

You can impl AOP using many different techniques. I proposed the
simplest one (used by Spring, Guice etc.). Using a regular JDK Dynamic
Proxy (which is the 'build in Java reflect proxy thingy'). What is
your question?

>> >
>> > So, what does AOP give us that can't be done at another phase?

AOP is not about a specific phase. It can be done at:
* compile time
* class load time
* runtime

Can be done with:
* Bytecode mods
* Generated proxy
* Dynamic proxy
* JVM-level hooks

>> >
>>
>> Semantics to annotations.
>
> Can you help out with an example?

Annotate a class with f.e.
@transactional(type=Required)  class Foo { ..}
and have all methods in this class being invoked under a transaction
with Required semantics

or annotate a specific method
@transactional(type=RequiresNew)  def foo { ..}
to get the same behavior for a method only

Annotations is the way most JEE devs are used to handle these things
since it is the approach both Spring, Guice, EJB 3 etc. etc. has
taken.

The stuff I have written allow using AspectJ pointcuts as well.
E.g. f.e. apply transactions to all methods in the service layer:
match('* com.biz.service.*(..)')

Or to a specific method:
match('void Store.buy(Item)')

But you could just use call-by-name:

transactional(TransactionType.Required) { // tx begin
  .. // do stuff in TX
}  // tx commit or rollback

But that pollutes the code, makes it harder to change, configure and
is not declarative.
Perhaps give the user options?

But you guys choose.
I am here to serve :-)

/Jonas

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



-- 
Jonas Bonér | Crisp AB

http://jonasboner.com
http://crisp.se

--~--~-~--~~~---~--~~
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: [Lift committers] Re: Meeting

[Josh Suereth]

>
>> > I am firmly against anything that re-writes byte-code after the
>> compilation
>> > phase for production code.  Once the Scala-Maven plugin supports
>> compiler
>> > plugins, then there's a lot of stuff that can be done at compile-time.
>>
>

The scala-maven plugin already supports compiler plugins.   Feel free to
make use of it as I do.

 (yes this is unrelated).

BTW - Most cases where aspects would have been useful in Java, I'd rather
see some kind of DSL.

E.g. Transactions  -

def doSomeWork() {
   transactional {
//My Trasnactional code
   }
   //Wow, I can even do stuff outside the transaction look at me go
}


The one use of annotations I see as being handy is how it's used in the
Eclipse plugin (i.e. fix a flaw the JDT Community is unwilling to fix).

--~--~-~--~~~---~--~~
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: [Lift committers] Re: Meeting

[David Pollak]

Taking the discussion to the main list

On Thu, Apr 16, 2009 at 10:23 AM, Jonas Bonér  wrote:

>
> 2009/4/16 David Pollak :
> >
> >
> > On Thu, Apr 16, 2009 at 7:08 AM, Jonas Bonér 
> wrote:
> >>
> >> 2009/4/16 David Pollak :
> >> > It'd be optimal if you could discuss the JTA stuff in the public
> forum.
> >> >  In
> >> > terms of AOP, I'm really not kidding that AOP is not going to happen
> in
> >> > Lift.
> >>
> >> You don't like annotations? E.g. @Transactional etc.?
> >
> > I'm not keen on annotations, but I can live with them.
> >
> > I am firmly against anything that re-writes byte-code after the
> compilation
> > phase for production code.  Once the Scala-Maven plugin supports compiler
> > plugins, then there's a lot of stuff that can be done at compile-time.
>
> The AOP stuff I have done is based on dynamic proxies no bytecode munging.


OKay... I need to see some example to fully understand why a proxy needs AOP
rather than either (1) compile-time proxy generation or (2) the built-in
Java reflect proxy thingy.


>
>
> >
> > So, what does AOP give us that can't be done at another phase?
> >
>
> Semantics to annotations.


Can you help out with an example?

Thanks,

David




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

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