- I'm pretty close to having a releasable version of the maven-scala-plugin
that supports compiler plugins.
- Adding integration between the maven-pom and eclipse is going to take some
time (but is "possible"). I'm not sure about the netbeans/IntelliJ tools,
but this could be an awkward integration for all of them.
Don't know if that helps. (Personally I think compiler plugins are better
for POCs).
On Mon, Dec 1, 2008 at 1:22 PM, David Pollak
<[EMAIL PROTECTED]>wrote:
> My 2 cents:
>
> - I'm strongly opposed to any compiler plugins as they (1) mean that
> IDEs will work less well and (2) they require some sort of installation (if
> they can be rolled into the Maven building stuff, it makes this objection
> go
> away)
> - I'm strongly opposed to mixing annotations and the Record stuff.
> It'll just make for wicked ugly looking code.
>
> I believe there are ways to use Record's deep knowledge of class layouts to
> generate data structures and/or XML to send to JPA to "do the right thing."
>
>
> On Sun, Nov 30, 2008 at 7:45 AM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote:
>
>> The whole point of integrating (and I use the word integrating here
>> loosely) is so that there's a common form framework for people to use.
>> Really, the point of Record as far as I can tell is to loosen and/or remove
>> the tight coupling with the datastore, and in that sense Record is
>> succeeding. As Tim points out, there are going to be people with existing
>> JPA libraries and what we're trying to propose is a means for them to
>> leverage their existing libraries alongside the nice work done in Record. As
>> ugly as the boilerplate for delegation may seem, I don't see any better
>> solution without adding significant complexity. I've done bytecode
>> manipulation in the past and while it can be very handy, it makes things a
>> lot more complex on the backend and I'm really trying to avoid complexity
>> (this includes a compiler plugin, too).
>>
>> Delegation provides the cleanest approach I can come up with; it actually
>> helps in the case where someone wants to use an existing JPA library because
>> you could simply wrap an instance and delegate to it:
>>
>> class MyEntry extends Record[MyEntry] {
>> var inner : RealEntry = _
>>
>> object name extends StringField(this) with Delegation
>> name.delegate(inner.name, inner.name = _)
>>
>> ...
>> }
>>
>> By adding a few lines of boilerplate in each class you get validation,
>> form generation, presentation HTML, JSON representation, etc. It's up to the
>> end-user to determine whether these features are worth the cost of a few
>> LoC.
>>
>> I'm not saying this is a perfect solution, just that I think that this is
>> the best first cut at it. Also, no one is saying that people have to use JPA
>> with Record. I'm assuming that the majority of new Lift apps will probably
>> use Record/Mapper because they're simple, easy to use and quite capable of
>> handling most data models. But for the people with existing JPA libraries,
>> or for people who would like to use JPA for the additional features,
>> compatibility with Java apps, etc, I'd like to have a better answer than an
>> absolute "Don't use Record" or "Switch to Record".
>>
>> Derek
>>
>>
>>
>> On Sun, Nov 30, 2008 at 1:40 AM, Marius <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I totally agree with you Viktor! ... although it seems like a workable
>>> solution in this case a Record contains to distinct entities to
>>> represent the same data and of course the boilerplate.
>>>
>>> It was mentioned above compiler plugins which I expressed my opinion
>>> about it (I'd stay away) but there might be another way to "alter" the
>>> bytecode at runtime. I'm talking about dynamic class weaving.
>>> Basically it is a class loader that before returning the actual
>>> updated class. Kind of what AspectJ is doing. A while ago a wrote a
>>> bytecode level manipulation framework and combined with a "special"
>>> classloader I was able to modify a class dynamically and use it.
>>>
>>> Of course there are caveats:
>>>
>>> 1. Complexity induced by bytecode level manipulation
>>> 2. How a dynamic class loader cope with container's classloader that
>>> essentially loads the web application. Of course it would delegate the
>>> loading to the container's classloader but these "modifiable" classes
>>> should probably not live in WEB-INF/classes or WEB-INF/lib folder.
>>>
>>>
>>> But all in all I'm not convinced that this effort really worth it.
>>> AFAIC I still don;t get the whole point of integrating Record/Field
>>> with JPA. If someone wants to switch easily from JPA to Record or vice-
>>> versa, to have this flexibility perhaps consider to abstract these
>>> layers from the rest of the application and using other persistence
>>> technologies would not affect the application "business logic" ... but
>>> this is about how the appliation is designed etc.
>>>
>>> Br's,
>>> Marius
>>>
>>> On Nov 30, 9:56 am, "Viktor Klang" <[EMAIL PROTECTED]> wrote:
>>> > IMHO:
>>> >
>>> > " @Column{val name = "my_name"}
>>> > var name : String = _
>>> > object nameField extends StringField(this,100) with Delegated
>>> > nameField.delegate(name, name = _)"
>>> >
>>> > That's just too much boilerplate. For me, who went to scala to lose
>>> > boilerplate, this is not a viable solution.
>>> >
>>> > Unfortunately the JPA spec is kind of weak when it comes to adaptation,
>>> so
>>> > my suggestion to make it work with Hibernate first still stands.
>>> >
>>> > What do you guys think?
>>> >
>>> > Cheers,
>>> > Viktor
>>> >
>>> > On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker
>>> > <[EMAIL PROTECTED]>wrote:
>>> >
>>> >
>>> >
>>> > > No big deal. In the example code I did a by-name in the delegate
>>> method so
>>> > > at least it's transparent to the end-user.
>>> >
>>> > > Derek
>>> >
>>> > > On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz <[EMAIL PROTECTED]
>>> >wrote:
>>> >
>>> > >> Just wanted to chime in real quick...
>>> >
>>> > >>> type Getter = () => MyType // Can this be by-name in any way?
>>> >
>>> > >> No. By-names are not first-class types. It's gotta be () => MyType
>>> >
>>> > >> --j
>>> >
>>> > --
>>> > Viktor Klang
>>> > Senior Systems Analyst
>>>
>>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
