Well, I don't necessarily think that's a bad idea. In fact, I was thinking
about that as well last night. I'm really not familiar at all with how
complex it would be to write a compiler plugin, or how easy that would be to
integrate with Maven. What I was thinking of, at least, was combining a
compiler plugin and somehow transposing JPA annotations that appear on a
Record field onto a generated getter/setter pair. Thus:
class MyEntry extends Record[MyEntry] {
@Column{val name = "my_name"}
object name extends StringField(this,100)
}
would become:
class MyEntry extends Record[MyEntry] {
object name extends StringField(this,100)
@Column{val name = "my_name"}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
}
Is there anyone here who can comment on how viable that is, or should I ask
on the Scala list?
Thanks,
Derek
On Wed, Nov 26, 2008 at 1:00 AM, Mateusz Fiołka <[EMAIL PROTECTED]>wrote:
> I'm not sure if my idea is good but I think that wrong ideas are better the
> none so I post it. Some time ago there was a discussion about using scala
> compiler plugins to simplify lift users experience. I'm not sure what are
> your opinions about using it in lift, however I guess it could help alot in
> this case. Class extending Record could be specially treated by compiler and
> thus record objects could be specified in a very simple way. I know there is
> added dependency to the build process but imho it's much better then using
> code generators because it is one of the compilation phases and it must be
> run for the code to compile.
>
>
>
>
> On Tue, Nov 25, 2008 at 10:29 PM, Kris Nuttycombe <
> [EMAIL PROTECTED]> wrote:
>
>> Ah, right, so if you're using property-based inference anyway, it's not an
>> issue. Never mind.
>>
>>
>> On Tue, Nov 25, 2008 at 2:26 PM, Derek Chen-Becker <[EMAIL PROTECTED]
>> > wrote:
>>
>>> On Tue, Nov 25, 2008 at 1:40 PM, Kris Nuttycombe <
>>> [EMAIL PROTECTED]> wrote:
>>>>
>>>> Remember that additionally in JPA, a bare unannotated field on an object
>>>> will be inferred as persistent unless annotated @Transient (or, in java,
>>>> unless it is declared with the "transient" modifier)
>>>>
>>>
>>> My reading of the JPA spec, section 2.1.1 is that persistent state is
>>> either field-based or property-based, and is determined by where you place
>>> your annotations. The @Transient is required for either method where you
>>> have a field or property that isn't supposed to be part of the state.
>>>
>>> Derek
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
