Hi Patrik,
On Sat, Aug 15, 2009 at 9:57 PM, Patrik
Nordwall<patrik.nordw...@gmail.com> wrote:
> PaloT wrote:
>> As part of our development we made some extensions which are maybe
>> interesting also for you. But before commit to SVN I would like to
>> discuss with you if it should be included in common code base:
>>
>> - FullAuditLog - extension to Auditing where all auditable Entities
>> remember oldValues for all fields (not references - for now). You can
>> get oldValue, newValue, list of changed attributes
>>
>
> I think this is a good optional feature.
For now I'm generating it instead of auditable. This mean that all
entities which are auditable are populated with FullAuditLog. What's
your opinion about this, is better to customize it per Entity or per
model in properties file? If per Entity we should use hints.
Another question is if fullAudit is extension to audit feature or is
totally separate?
>> - Make all setters for Auditable columns (createdBy, lastUpdatedBy,
>> ...) protected and generate method "@PrePersist protected
>> changeAuditInformation()" which will care about updating values
>> similar to AuditListener.changeAuditInformation (we should get rid of
>> AuditListener).
>>
>
> What is the advantage over AuditListener? Or is it needed for FullAuditLog?
Only reason is, easy code generation. I found some "abscure"
constructs for Entity level annotations. With listener it will be
difficult to call protected setUpdate.... methods.
>> - 'readonly' designator for Entity attributes and references, will
>> generate protected setter (maybe we can use new hint feature - already
>> in SVN), should be used also by GUI generators, it's very common
>> behavior
>>
> We talked about this in another thread. Is the purpose to generate public
> getter and protected setter? I don't think it should be mixed up with 'not
> changeable'. Do we need a special keyword in the dsl for this case or is it
> enough to use hint?
Here we should start with 'official' hint support. It will be sculptor
supported hint.
>> - generate @Name annotation for method parameters in services. Because
>> compiled classes doesn't carry method name parameters I have to
>> generate special annotation which allow qualify parameter names. For
>> example: public ListSettings save(@Name("ctx") ServiceContext ctx,
>> @Name("entity") ListSettings entity)
>>
>>
>
> Normally you would compile with debug information and then the names are
> preserved, I think. Anyway if you need it I don't mind adding it as an
> optional feature.
No, function parameter names aren't preserved. Strange thing in JVM
and class format.
> Thanks for your ideas. Create separate jira issues and go ahead.
OK. Still working on smartclient. I dislike some constructs but I will
commit first version.
95% of code is already in fornax package.
Pavel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
