If it was javadoc'd :), TECHNICALLY you could just use the javadoc,
but it might lead to confusion like you had, so probably a manually
maintained one that shows the common keys (formatted properly) might
be better.
On Jan 29, 2008, at 10:04 AM, John Huss wrote:
> Ah, dropping the "is" made it work --
> $fetchSpecification.fetchEnterpriseObjects
>
> Good suggestion.
>
> It would be nice to have a simple reference that showed the correct
> values for these things. Do you think such a thing could be
> generated from the EM source or would it have to be maintained by
> hand? I would guess the changes/additions to these keys would be
> fairly rare.
>
> Thanks,
> John
>
> On Jan 28, 2008 4:59 PM, Mike Schrag <mschra..dimension.com> wrote:
> What build of Eclipse and WOLips are you using? The definition of
> that method is pretty damn simple -- return rawRowKeyPaths == null;
> Maybe it's picky about the "is" in Velocity and you have to instead
> use !$fetchSpecification.fetchEnterpriseObjects ?
>
> ms
>
> On Jan 28, 2008, at 5:37 PM, John Huss wrote:
>
> > I think there may be a problem with the isFetchEnterpriseObjects
> > method for EOEntity using the Velocity generator.
> >
> > I have some template logic to handle raw rows vs EOs. The raw row
> > fetches are generating fine, but the regular EO ones aren't. For
> > example, for one plain EO fetch the following template produces this
> >
> > TEMPLATE PORTION:
> >
> > #if (!$fetchSpecification.isFetchEnterpriseObjects)
> > /**
> > * RAW ROW KEY PATHS:
> > #foreach ($keyPath in $fetchSpecification.rawRowKeyPaths)
> > * ${keyPath}
> > #end
> > */
> > #end
> >
> > RESULT:
> >
> > /**
> > * RAW ROW KEY PATHS:
> > */
> >
> > So the expression $fetchSpecification.isFetchEnterpriseObjects is
> > evaluating to false incorrectly when the fetch really does fetch
> > EOs. For the raw fetches I've verified that "rawRowKeyPaths"
> > returns the correct paths.
>
>
>
This archive was generated by hypermail 2.0.0 : Tue Jan 29 2008 - 11:01:14 EST