Going to open a JIRA today with 1.5 templates that can be used until
something along these lines can be implemented.
Let me know when you work on the generator. I don't mind taking the time to
add the parameter - but no sense in doing it now if its all gonna change
soon :)
Cris
> Cris Daniluk <cris.danilu..laraview.com> wrote:
> > This may be the cause of our disagreement. There's no
> reason to have 2
> > templates - they would be identical in every way but 2 List
> references.
> >
> > To clarify, a consolidated template is attached. The jdk15
> boolean param
> > would drive whether or not generics were used.
>
> Ok. I see what you're saying. For some reason I thought
> the changes would
> be more extensive than that.
>
> Let's clean it up a bit, though.
>
> -------------------------
> #if( $jdk15 ) public
> List<$classGen.formatJavaType(${rel.TargetEntity.ClassName})>
> get${classGen.cappedProp}() { return
> (List<$classGen.formatJavaType(${rel.TargetEntity.ClassName})>
> )readProperty("${rel.name}"); #else public List
> get${classGen.cappedProp}() { return
> (List)readProperty("${rel.name}"); #end -------------------------
>
> Could become:
>
> -------------------------
> public List#if( $jdk15
> )<$classGen.formatJavaType(${rel.TargetEntity.ClassName})>#end
> get${classGen.cappedProp}() { return (List#if( $jdk15
> )<$classGen.formatJavaType(${rel.TargetEntity.ClassName})>
> #end)readProperty("${rel.name}"); -------------------------
>
> We could also factor out the "List#if( $jdk15
> )<$classGen.formatJavaType(${rel.TargetEntity.ClassName})>#end
> " into a
> variable (List_type?) so it's more readable and maintainable,
> but for only
> two references, it's probably not worth it.
>
> I'm hoping to getting around to the classgen reorg soon (in
> the next month),
> so you could probably just append this to the end of JIRA CAY-79.
>
> -Mike
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 07 2005 - 08:59:50 EST