OFBiz › OFBiz - User

But in CategoryTree.groovy

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

SkipDever

But in CategoryTree.groovy

There is a line at 50 that sez:

prodCatalogs = delegator.findByAnd("ProdCatalog");

This causes a groovy ambiguious error when you go to the catalog screen in
12.04.

Changing this to:
prodCatalogs = delegator.findAll("ProdCatalog");

Fixes the problem.

I expect you guys already did this, there here it is for any others like me
that just download the zip file.

Skip

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

Thanks for report Skip,

BTW you must have missed something, findAll does not exist anymore for 3 years ;)
http://svn.apache.org/viewvc?view=revision&revision=938947

Using
prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null, false);
Should be the way. Could you please confirm before I commit?

Thanks

Jacques

From: "Skip" <[hidden email]>

> There is a line at 50 that sez:
>
> prodCatalogs = delegator.findByAnd("ProdCatalog");
>
> This causes a groovy ambiguious error when you go to the catalog screen in
> 12.04.
>
> Changing this to:
> prodCatalogs = delegator.findAll("ProdCatalog");
>
> Fixes the problem.
>
> I expect you guys already did this, there here it is for any others like me
> that just download the zip file.
>
> Skip
>

SkipDever

RE: But in CategoryTree.groovy

Jacques

That works fine. findAll() works for me because I added it back in.
findAll() is a better function to use because in my opinion, it sez exactly
what it does and that makes the code more readable. I have hundreds of java
files written over the years and it was way easier to add back in the
functionality you guys deprecated/removed than to replace all my entity
engine calls.

This time however, I put them all together so it would be easier next time
you guys do a major release.

BTW, I have had a few weeks now to go pretty thoroughly through lots of this
code and it is very nice. I am especially pleased with the re-write of the
widget code and the use of jquery.

Skip

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Thursday, May 30, 2013 6:38 AM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

Thanks for report Skip,

BTW you must have missed something, findAll does not exist anymore for 3
years ;)
http://svn.apache.org/viewvc?view=revision&revision=938947

Using
prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
false);
Should be the way. Could you please confirm before I commit?

Thanks

Jacques

From: "Skip" <[hidden email]>

me
> that just download the zip file.
>
> Skip
>

SkipDever

RE: But in CategoryTree.groovy

In reply to this post by Jacques Le Roux

BTW

There is still another bug. I am probably the only one that uses it, but
you cannot extend a view entity. Give it a try. I detailed it pretty
thoroughly in a previous email. It is repeated here:

As a test, I extended OrderHeaderAndItems in a different module in exactly
the same way and got the same error.

Here is the extend that is causing the error. It is exactly the same as my
9.x version which works fine:
<extend-entity entity-name="WorkEffortAndPartyAssign">
<relation type="one-nofk" title="Current"
rel-entity-name="StatusItem">
<key-map field-name="currentStatusId"
rel-field-name="statusId"/>
</relation>
<relation type="one-nofk" rel-entity-name="WorkEffortType">
<key-map field-name="workEffortTypeId"/>
</relation>
<relation type="one-nofk" rel-entity-name="WorkEffortPurposeType">
<key-map field-name="workEffortPurposeTypeId"/>
</relation>
</extend-entity>

As a further test, I commented these out from jobshop and I copied this
extend-entity into the same entitymodel_view.xml file as the the definition
for WorkEffortAndPartyAssign in the workeffort project and got exactly the
same error.

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Thursday, May 30, 2013 6:38 AM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

Thanks for report Skip,

BTW you must have missed something, findAll does not exist anymore for 3
years ;)
http://svn.apache.org/viewvc?view=revision&revision=938947

Using
prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
false);
Should be the way. Could you please confirm before I commit?

Thanks

Jacques

From: "Skip" <[hidden email]>

me
> that just download the zip file.
>
> Skip
>

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

In reply to this post by SkipDever

About findAll(), yes it's a moot point

David got into this direction 5 years ago and nobody was really against it
http://markmail.org/message/thcsl7khketkqagh

One of the ideas was to get rif of all the variations and use rather parameters, take for instance
http://svn.apache.org/viewvc?view=revision&revision=938948

IMO, Jonathan had a good point about owen buttons in the thread above
One thing we would consider is reintroducing most simplifed ones, like findAll(), yes!

But maybe Scott would be agains it
http://svn.apache.org/viewvc?view=revision&revision=938947

Opinions?

Jacques

From: "Skip" <[hidden email]>

> Jacques
>
> That works fine. findAll() works for me because I added it back in.
> findAll() is a better function to use because in my opinion, it sez exactly
> what it does and that makes the code more readable. I have hundreds of java
> files written over the years and it was way easier to add back in the
> functionality you guys deprecated/removed than to replace all my entity
> engine calls.
>
> This time however, I put them all together so it would be easier next time
> you guys do a major release.
>
> BTW, I have had a few weeks now to go pretty thoroughly through lots of this
> code and it is very nice. I am especially pleased with the re-write of the
> widget code and the use of jquery.
>
> Skip
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Thursday, May 30, 2013 6:38 AM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Thanks for report Skip,
>
> BTW you must have missed something, findAll does not exist anymore for 3
> years ;)
> http://svn.apache.org/viewvc?view=revision&revision=938947
>
> Using
> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
> false);
> Should be the way. Could you please confirm before I commit?
>
> Thanks
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> There is a line at 50 that sez:
>>
>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>
>> This causes a groovy ambiguious error when you go to the catalog screen in
>> 12.04.
>>
>> Changing this to:
>> prodCatalogs = delegator.findAll("ProdCatalog");
>>
>> Fixes the problem.
>>
>> I expect you guys already did this, there here it is for any others like
> me
>> that just download the zip file.
>>
>> Skip
>>
>

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

In reply to this post by SkipDever

Last pragmatic cons note for findAll("EntityName"),
instead of findList("EntityName", null, null, null, null, false)

It's much easier to remember when you have to use it in envs where there is no auto-completer, like Groovy scripts in Eclipse.

This would mean to revert r938947 and I guess some others commits, not sure all will agree...

If ever we agree on this. Are there other high level methods (like findAll("EntityName"), ie w/o parameters just EntityName) we would reintroduce?

Jacques

Jacques Le Roux wrote:

> About findAll(), yes it's a moot point
>
> David got into this direction 5 years ago and nobody was really against it
> http://markmail.org/message/thcsl7khketkqagh
>
> One of the ideas was to get rif of all the variations and use rather parameters, take for instance
> http://svn.apache.org/viewvc?view=revision&revision=938948
>
> IMO, Jonathan had a good point about owen buttons in the thread above
> One thing we would consider is reintroducing most simplifed ones, like findAll(), yes!
>
> But maybe Scott would be agains it
> http://svn.apache.org/viewvc?view=revision&revision=938947
>
> Opinions?
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> Jacques
>>
>> That works fine. findAll() works for me because I added it back in.
>> findAll() is a better function to use because in my opinion, it sez exactly
>> what it does and that makes the code more readable. I have hundreds of java
>> files written over the years and it was way easier to add back in the
>> functionality you guys deprecated/removed than to replace all my entity
>> engine calls.
>>
>> This time however, I put them all together so it would be easier next time
>> you guys do a major release.
>>
>> BTW, I have had a few weeks now to go pretty thoroughly through lots of this
>> code and it is very nice. I am especially pleased with the re-write of the
>> widget code and the use of jquery.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Jacques Le Roux [mailto:[hidden email]]
>> Sent: Thursday, May 30, 2013 6:38 AM
>> To: [hidden email]
>> Subject: Re: But in CategoryTree.groovy
>>
>>
>> Thanks for report Skip,
>>
>> BTW you must have missed something, findAll does not exist anymore for 3
>> years ;)
>> http://svn.apache.org/viewvc?view=revision&revision=938947
>>
>> Using
>> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
>> false);
>> Should be the way. Could you please confirm before I commit?
>>
>> Thanks
>>
>> Jacques
>>
>> From: "Skip" <[hidden email]>
>>> There is a line at 50 that sez:
>>>
>>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>>
>>> This causes a groovy ambiguious error when you go to the catalog screen in
>>> 12.04.
>>>
>>> Changing this to:
>>> prodCatalogs = delegator.findAll("ProdCatalog");
>>>
>>> Fixes the problem.
>>>
>>> I expect you guys already did this, there here it is for any others like
>> me
>>> that just download the zip file.
>>>
>>> Skip

SkipDever

RE: But in CategoryTree.groovy

In reply to this post by Jacques Le Roux

In my opinion, one thing to consider is the monumental amount of code out
there that depends on the Ofbiz core. Ofbiz is not generally usable ootb.
It requires considerable modification and additions for industry specific
needs. I myself have 321 java files containing 6+ million bytes of code and
maybe as many bsh scripts that make calls to the entity engine and that is
for 1 of 4 installations I have done.I am sure that I am only one of many.

As for findAll(), it makes good sense if someone wants to deprecate it.
After a while, you get annoyed at the deprecation warnings and you fix your
code to use the recommended version. It makes almost no sense to remove it
altogether unless the underlying logic has also been removed because of a
conflict. It amounts to about 10 bytes in the jar file calling another
function with null arguments.

Also, findAll does what it says. findList(...) requires a comment for
others less familiar with the entity engine who maintain this code. We have
only one developer with Ofbiz skills. We have many more with great java
skills that work on the same code base. It makes sense to me to make it as
easy to read and understand especially considering the dearth of comments in
the javadoc.

I agree that it is a moot point. I have added all these removed functions
(the few I use) back in and my jar file increased 98 bytes. Problem solved.

BTW, getting into more and more of this and it was a great job you guys have
done with the lookup screens automatically generating JSON for
auto-completion.

Skip

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Thursday, May 30, 2013 12:33 PM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

About findAll(), yes it's a moot point

David got into this direction 5 years ago and nobody was really against it
http://markmail.org/message/thcsl7khketkqagh

One of the ideas was to get rif of all the variations and use rather
parameters, take for instance
http://svn.apache.org/viewvc?view=revision&revision=938948

IMO, Jonathan had a good point about owen buttons in the thread above
One thing we would consider is reintroducing most simplifed ones, like
findAll(), yes!

But maybe Scott would be agains it
http://svn.apache.org/viewvc?view=revision&revision=938947

Opinions?

Jacques

From: "Skip" <[hidden email]>
> Jacques
>
> That works fine. findAll() works for me because I added it back in.
> findAll() is a better function to use because in my opinion, it sez
exactly
> what it does and that makes the code more readable. I have hundreds of
java
> files written over the years and it was way easier to add back in the
> functionality you guys deprecated/removed than to replace all my entity
> engine calls.
>
> This time however, I put them all together so it would be easier next time
> you guys do a major release.
>
> BTW, I have had a few weeks now to go pretty thoroughly through lots of
this
> code and it is very nice. I am especially pleased with the re-write of
the

> widget code and the use of jquery.
>
> Skip
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Thursday, May 30, 2013 6:38 AM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Thanks for report Skip,
>
> BTW you must have missed something, findAll does not exist anymore for 3
> years ;)
> http://svn.apache.org/viewvc?view=revision&revision=938947
>
> Using
> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
> false);
> Should be the way. Could you please confirm before I commit?
>
> Thanks
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> There is a line at 50 that sez:
>>
>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>
>> This causes a groovy ambiguious error when you go to the catalog screen

>> 12.04.
>>
>> Changing this to:
>> prodCatalogs = delegator.findAll("ProdCatalog");
>>
>> Fixes the problem.
>>
>> I expect you guys already did this, there here it is for any others like
> me
>> that just download the zip file.
>>
>> Skip
>>
>

Deepak Agarwal-2

Re: But in CategoryTree.groovy

In reply to this post by Jacques Le Roux

I might have missed something but findList("EntityName", null, null, null,
null, false) doesn't work for me from ftl because of 'null' .

On Fri, May 31, 2013 at 1:13 AM, Jacques Le Roux <
[hidden email]> wrote:

> Last pragmatic cons note for findAll("EntityName"),
> instead of findList("EntityName", null, null, null, null, false)
>
> It's much easier to remember when you have to use it in envs where there
> is no auto-completer, like Groovy scripts in Eclipse.
>
> This would mean to revert r938947 and I guess some others commits, not
> sure all will agree...
>
> If ever we agree on this. Are there other high level methods (like
> findAll("EntityName"), ie w/o parameters just EntityName) we would
> reintroduce?
>
> Jacques
>
> Jacques Le Roux wrote:
> > About findAll(), yes it's a moot point
> >
> > David got into this direction 5 years ago and nobody was really against
> it
> > http://markmail.org/message/thcsl7khketkqagh
> >
> > One of the ideas was to get rif of all the variations and use rather
> parameters, take for instance
> > http://svn.apache.org/viewvc?view=revision&revision=938948
> >
> > IMO, Jonathan had a good point about owen buttons in the thread above
> > One thing we would consider is reintroducing most simplifed ones, like
> findAll(), yes!
> >
> > But maybe Scott would be agains it
> > http://svn.apache.org/viewvc?view=revision&revision=938947
> >
> > Opinions?
> >
> > Jacques
> >
> > From: "Skip" <[hidden email]>
> >> Jacques
> >>
> >> That works fine. findAll() works for me because I added it back in.
> >> findAll() is a better function to use because in my opinion, it sez
> exactly
> >> what it does and that makes the code more readable. I have hundreds of
> java
> >> files written over the years and it was way easier to add back in the
> >> functionality you guys deprecated/removed than to replace all my entity
> >> engine calls.
> >>
> >> This time however, I put them all together so it would be easier next
> time
> >> you guys do a major release.
> >>
> >> BTW, I have had a few weeks now to go pretty thoroughly through lots of
> this
> >> code and it is very nice. I am especially pleased with the re-write of
> the
> >> widget code and the use of jquery.
> >>
> >> Skip
> >>
> >> -----Original Message-----
> >> From: Jacques Le Roux [mailto:[hidden email]]
> >> Sent: Thursday, May 30, 2013 6:38 AM
> >> To: [hidden email]
> >> Subject: Re: But in CategoryTree.groovy
> >>
> >>
> >> Thanks for report Skip,
> >>
> >> BTW you must have missed something, findAll does not exist anymore for 3
> >> years ;)
> >> http://svn.apache.org/viewvc?view=revision&revision=938947
> >>
> >> Using
> >> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
> >> false);
> >> Should be the way. Could you please confirm before I commit?
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >> From: "Skip" <[hidden email]>
> >>> There is a line at 50 that sez:
> >>>
> >>> prodCatalogs = delegator.findByAnd("ProdCatalog");
> >>>
> >>> This causes a groovy ambiguious error when you go to the catalog
> screen in
> >>> 12.04.
> >>>
> >>> Changing this to:
> >>> prodCatalogs = delegator.findAll("ProdCatalog");
> >>>
> >>> Fixes the problem.
> >>>
> >>> I expect you guys already did this, there here it is for any others
> like
> >> me
> >>> that just download the zip file.
> >>>
> >>> Skip
>

--
Thanks,
Deepak Agarwal,

Mobile: +91 9501190044

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

In reply to this post by SkipDever

Thanks Skip,

Fixed in trunk at revision: 1488188
R12.04 r1488193

Others had conflicts and I guess were not needed

Jacques

From: "Skip" <[hidden email]>

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

In reply to this post by Deepak Agarwal-2

I just tried by adding
<#assign orderHeaders = delegator.findList("OrderHeader", null, null, null, null, false)/>
orderHeaders=========${orderHeaders}

to OrderSalesReps.ftl in trunk locally, works perfectly

Which release.revision are you using?

Jacques

From: "Deepak Agarwal" <[hidden email]>

>I might have missed something but findList("EntityName", null, null, null,
> null, false) doesn't work for me from ftl because of 'null' .
>
> On Fri, May 31, 2013 at 1:13 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Last pragmatic cons note for findAll("EntityName"),
>> instead of findList("EntityName", null, null, null, null, false)
>>
>> It's much easier to remember when you have to use it in envs where there
>> is no auto-completer, like Groovy scripts in Eclipse.
>>
>> This would mean to revert r938947 and I guess some others commits, not
>> sure all will agree...
>>
>> If ever we agree on this. Are there other high level methods (like
>> findAll("EntityName"), ie w/o parameters just EntityName) we would
>> reintroduce?
>>
>> Jacques
>>
>> Jacques Le Roux wrote:
>> > About findAll(), yes it's a moot point
>> >
>> > David got into this direction 5 years ago and nobody was really against
>> it
>> > http://markmail.org/message/thcsl7khketkqagh
>> >
>> > One of the ideas was to get rif of all the variations and use rather
>> parameters, take for instance
>> > http://svn.apache.org/viewvc?view=revision&revision=938948
>> >
>> > IMO, Jonathan had a good point about owen buttons in the thread above
>> > One thing we would consider is reintroducing most simplifed ones, like
>> findAll(), yes!
>> >
>> > But maybe Scott would be agains it
>> > http://svn.apache.org/viewvc?view=revision&revision=938947
>> >
>> > Opinions?
>> >
>> > Jacques
>> >
>> > From: "Skip" <[hidden email]>
>> >> Jacques
>> >>
>> >> That works fine. findAll() works for me because I added it back in.
>> >> findAll() is a better function to use because in my opinion, it sez
>> exactly
>> >> what it does and that makes the code more readable. I have hundreds of
>> java
>> >> files written over the years and it was way easier to add back in the
>> >> functionality you guys deprecated/removed than to replace all my entity
>> >> engine calls.
>> >>
>> >> This time however, I put them all together so it would be easier next
>> time
>> >> you guys do a major release.
>> >>
>> >> BTW, I have had a few weeks now to go pretty thoroughly through lots of
>> this
>> >> code and it is very nice. I am especially pleased with the re-write of
>> the
>> >> widget code and the use of jquery.
>> >>
>> >> Skip
>> >>
>> >> -----Original Message-----
>> >> From: Jacques Le Roux [mailto:[hidden email]]
>> >> Sent: Thursday, May 30, 2013 6:38 AM
>> >> To: [hidden email]
>> >> Subject: Re: But in CategoryTree.groovy
>> >>
>> >>
>> >> Thanks for report Skip,
>> >>
>> >> BTW you must have missed something, findAll does not exist anymore for 3
>> >> years ;)
>> >> http://svn.apache.org/viewvc?view=revision&revision=938947
>> >>
>> >> Using
>> >> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
>> >> false);
>> >> Should be the way. Could you please confirm before I commit?
>> >>
>> >> Thanks
>> >>
>> >> Jacques
>> >>
>> >> From: "Skip" <[hidden email]>
>> >>> There is a line at 50 that sez:
>> >>>
>> >>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>> >>>
>> >>> This causes a groovy ambiguious error when you go to the catalog
>> screen in
>> >>> 12.04.
>> >>>
>> >>> Changing this to:
>> >>> prodCatalogs = delegator.findAll("ProdCatalog");
>> >>>
>> >>> Fixes the problem.
>> >>>
>> >>> I expect you guys already did this, there here it is for any others
>> like
>> >> me
>> >>> that just download the zip file.
>> >>>
>> >>> Skip
>>
>
>
>
> --
> Thanks,
> Deepak Agarwal,
>
> Mobile: +91 9501190044
>

Deepak Agarwal-2

Re: But in CategoryTree.groovy

Sorry, It's working. I remember getting an error of nullField sometime ago
and therefore stopped using this version of findList and started passing a
list from screen using <entity-condition>.

On Fri, May 31, 2013 at 6:50 PM, Jacques Le Roux <
[hidden email]> wrote:

> I just tried by adding
> <#assign orderHeaders = delegator.findList("OrderHeader", null, null,
> null, null, false)/>
> orderHeaders=========${orderHeaders}
>
> to OrderSalesReps.ftl in trunk locally, works perfectly
>
> Which release.revision are you using?
>
> Jacques
>
> From: "Deepak Agarwal" <[hidden email]>
> >I might have missed something but findList("EntityName", null, null, null,
> > null, false) doesn't work for me from ftl because of 'null' .
> >
> > On Fri, May 31, 2013 at 1:13 AM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Last pragmatic cons note for findAll("EntityName"),
> >> instead of findList("EntityName", null, null, null, null, false)
> >>
> >> It's much easier to remember when you have to use it in envs where there
> >> is no auto-completer, like Groovy scripts in Eclipse.
> >>
> >> This would mean to revert r938947 and I guess some others commits, not
> >> sure all will agree...
> >>
> >> If ever we agree on this. Are there other high level methods (like
> >> findAll("EntityName"), ie w/o parameters just EntityName) we would
> >> reintroduce?
> >>
> >> Jacques
> >>
> >> Jacques Le Roux wrote:
> >> > About findAll(), yes it's a moot point
> >> >
> >> > David got into this direction 5 years ago and nobody was really
> against
> >> it
> >> > http://markmail.org/message/thcsl7khketkqagh
> >> >
> >> > One of the ideas was to get rif of all the variations and use rather
> >> parameters, take for instance
> >> > http://svn.apache.org/viewvc?view=revision&revision=938948
> >> >
> >> > IMO, Jonathan had a good point about owen buttons in the thread above
> >> > One thing we would consider is reintroducing most simplifed ones, like
> >> findAll(), yes!
> >> >
> >> > But maybe Scott would be agains it
> >> > http://svn.apache.org/viewvc?view=revision&revision=938947
> >> >
> >> > Opinions?
> >> >
> >> > Jacques
> >> >
> >> > From: "Skip" <[hidden email]>
> >> >> Jacques
> >> >>
> >> >> That works fine. findAll() works for me because I added it back in.
> >> >> findAll() is a better function to use because in my opinion, it sez
> >> exactly
> >> >> what it does and that makes the code more readable. I have hundreds
> of
> >> java
> >> >> files written over the years and it was way easier to add back in the
> >> >> functionality you guys deprecated/removed than to replace all my
> entity
> >> >> engine calls.
> >> >>
> >> >> This time however, I put them all together so it would be easier next
> >> time
> >> >> you guys do a major release.
> >> >>
> >> >> BTW, I have had a few weeks now to go pretty thoroughly through lots
> of
> >> this
> >> >> code and it is very nice. I am especially pleased with the re-write
> of
> >> the
> >> >> widget code and the use of jquery.
> >> >>
> >> >> Skip
> >> >>
> >> >> -----Original Message-----
> >> >> From: Jacques Le Roux [mailto:[hidden email]]
> >> >> Sent: Thursday, May 30, 2013 6:38 AM
> >> >> To: [hidden email]
> >> >> Subject: Re: But in CategoryTree.groovy
> >> >>
> >> >>
> >> >> Thanks for report Skip,
> >> >>
> >> >> BTW you must have missed something, findAll does not exist anymore
> for 3
> >> >> years ;)
> >> >> http://svn.apache.org/viewvc?view=revision&revision=938947
> >> >>
> >> >> Using
> >> >> prodCatalogs = delegator.findList("ProdCatalog", null, null, null,
> null,
> >> >> false);
> >> >> Should be the way. Could you please confirm before I commit?
> >> >>
> >> >> Thanks
> >> >>
> >> >> Jacques
> >> >>
> >> >> From: "Skip" <[hidden email]>
> >> >>> There is a line at 50 that sez:
> >> >>>
> >> >>> prodCatalogs = delegator.findByAnd("ProdCatalog");
> >> >>>
> >> >>> This causes a groovy ambiguious error when you go to the catalog
> >> screen in
> >> >>> 12.04.
> >> >>>
> >> >>> Changing this to:
> >> >>> prodCatalogs = delegator.findAll("ProdCatalog");
> >> >>>
> >> >>> Fixes the problem.
> >> >>>
> >> >>> I expect you guys already did this, there here it is for any others
> >> like
> >> >> me
> >> >>> that just download the zip file.
> >> >>>
> >> >>> Skip
> >>
> >
> >
> >
> > --
> > Thanks,
> > Deepak Agarwal,
> >
> > Mobile: +91 9501190044
> >
>

--
Thanks,
Deepak Agarwal,

Mobile: +91 9501190044

SkipDever

RE: But in CategoryTree.groovy

In reply to this post by Deepak Agarwal-2

I tried it and it worked fine for me. It flunked the first time because I
was short one of the nulls.

Skip

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On
Behalf Of Deepak Agarwal
Sent: Friday, May 31, 2013 3:59 AM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

I might have missed something but findList("EntityName", null, null, null,
null, false) doesn't work for me from ftl because of 'null' .

On Fri, May 31, 2013 at 1:13 AM, Jacques Le Roux <
[hidden email]> wrote:

3
> >> years ;)
> >> http://svn.apache.org/viewvc?view=revision&revision=938947
> >>
> >> Using
> >> prodCatalogs = delegator.findList("ProdCatalog", null, null, null,
null,

> >> false);
> >> Should be the way. Could you please confirm before I commit?
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >> From: "Skip" <[hidden email]>
> >>> There is a line at 50 that sez:
> >>>
> >>> prodCatalogs = delegator.findByAnd("ProdCatalog");
> >>>
> >>> This causes a groovy ambiguious error when you go to the catalog
> screen in
> >>> 12.04.
> >>>
> >>> Changing this to:
> >>> prodCatalogs = delegator.findAll("ProdCatalog");
> >>>
> >>> Fixes the problem.
> >>>
> >>> I expect you guys already did this, there here it is for any others
> like
> >> me
> >>> that just download the zip file.
> >>>
> >>> Skip
>

--
Thanks,
Deepak Agarwal,

Mobile: +91 9501190044

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

In reply to this post by SkipDever

Adrian said it's possible, since there are no OOTB examples I'm not so sure (I never tried IIRW)
Here are 3 years old answers which might help

http://markmail.org/message/4d3gjql3xkuifmrg

Jacques

From: "Skip" <[hidden email]>

> BTW
>
> There is still another bug. I am probably the only one that uses it, but
> you cannot extend a view entity. Give it a try. I detailed it pretty
> thoroughly in a previous email. It is repeated here:
>
> As a test, I extended OrderHeaderAndItems in a different module in exactly
> the same way and got the same error.
>
> Here is the extend that is causing the error. It is exactly the same as my
> 9.x version which works fine:
> <extend-entity entity-name="WorkEffortAndPartyAssign">
> <relation type="one-nofk" title="Current"
> rel-entity-name="StatusItem">
> <key-map field-name="currentStatusId"
> rel-field-name="statusId"/>
> </relation>
> <relation type="one-nofk" rel-entity-name="WorkEffortType">
> <key-map field-name="workEffortTypeId"/>
> </relation>
> <relation type="one-nofk" rel-entity-name="WorkEffortPurposeType">
> <key-map field-name="workEffortPurposeTypeId"/>
> </relation>
> </extend-entity>
>
> As a further test, I commented these out from jobshop and I copied this
> extend-entity into the same entitymodel_view.xml file as the the definition
> for WorkEffortAndPartyAssign in the workeffort project and got exactly the
> same error.
>
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Thursday, May 30, 2013 6:38 AM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Thanks for report Skip,
>
> BTW you must have missed something, findAll does not exist anymore for 3
> years ;)
> http://svn.apache.org/viewvc?view=revision&revision=938947
>
> Using
> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
> false);
> Should be the way. Could you please confirm before I commit?
>
> Thanks
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> There is a line at 50 that sez:
>>
>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>
>> This causes a groovy ambiguious error when you go to the catalog screen in
>> 12.04.
>>
>> Changing this to:
>> prodCatalogs = delegator.findAll("ProdCatalog");
>>
>> Fixes the problem.
>>
>> I expect you guys already did this, there here it is for any others like
> me
>> that just download the zip file.
>>
>> Skip
>>
>

SkipDever

RE: But in CategoryTree.groovy

view-entity used to be able to be extended. I used it in several places in
9.x. They are supposed to be extendable currently in entitymodel.xsd.

However, if you extend one, you get a runtime error about the base
view-entity not existing even when the base entity and the extended one are
in the same file.

Not a big deal as I just modified your view, but I like to keep my changes
in hot-deploy to make upgrading easier.

Skip

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Saturday, June 01, 2013 2:29 PM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

Adrian said it's possible, since there are no OOTB examples I'm not so sure
(I never tried IIRW)
Here are 3 years old answers which might help

http://markmail.org/message/4d3gjql3xkuifmrg

Jacques

From: "Skip" <[hidden email]>

> 9.x version which works fine:
> <extend-entity entity-name="WorkEffortAndPartyAssign">
> <relation type="one-nofk" title="Current"
> rel-entity-name="StatusItem">
> <key-map field-name="currentStatusId"
> rel-field-name="statusId"/>
> </relation>
> <relation type="one-nofk" rel-entity-name="WorkEffortType">
> <key-map field-name="workEffortTypeId"/>
> </relation>
> <relation type="one-nofk" rel-entity-name="WorkEffortPurposeType">
> <key-map field-name="workEffortPurposeTypeId"/>
> </relation>
> </extend-entity>
>
> As a further test, I commented these out from jobshop and I copied this
> extend-entity into the same entitymodel_view.xml file as the the

definition

> for WorkEffortAndPartyAssign in the workeffort project and got exactly the
> same error.
>
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Thursday, May 30, 2013 6:38 AM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Thanks for report Skip,
>
> BTW you must have missed something, findAll does not exist anymore for 3
> years ;)
> http://svn.apache.org/viewvc?view=revision&revision=938947
>
> Using
> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
> false);
> Should be the way. Could you please confirm before I commit?
>
> Thanks
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> There is a line at 50 that sez:
>>
>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>
>> This causes a groovy ambiguious error when you go to the catalog screen

Jacques Le Roux

Re: But in CategoryTree.groovy

Administrator

Thanks for report Skip,

So we lost a functionality, would you mind opening a Jira for that?

Thanks

Jacques

From: "Skip" <[hidden email]>

> view-entity used to be able to be extended. I used it in several places in
> 9.x. They are supposed to be extendable currently in entitymodel.xsd.
>
> However, if you extend one, you get a runtime error about the base
> view-entity not existing even when the base entity and the extended one are
> in the same file.
>
> Not a big deal as I just modified your view, but I like to keep my changes
> in hot-deploy to make upgrading easier.
>
> Skip
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Saturday, June 01, 2013 2:29 PM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Adrian said it's possible, since there are no OOTB examples I'm not so sure
> (I never tried IIRW)
> Here are 3 years old answers which might help
>
> http://markmail.org/message/4d3gjql3xkuifmrg
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> BTW
>>
>> There is still another bug. I am probably the only one that uses it, but
>> you cannot extend a view entity. Give it a try. I detailed it pretty
>> thoroughly in a previous email. It is repeated here:
>>
>> As a test, I extended OrderHeaderAndItems in a different module in exactly
>> the same way and got the same error.
>>
>> Here is the extend that is causing the error. It is exactly the same as
> my
>> 9.x version which works fine:
>> <extend-entity entity-name="WorkEffortAndPartyAssign">
>> <relation type="one-nofk" title="Current"
>> rel-entity-name="StatusItem">
>> <key-map field-name="currentStatusId"
>> rel-field-name="statusId"/>
>> </relation>
>> <relation type="one-nofk" rel-entity-name="WorkEffortType">
>> <key-map field-name="workEffortTypeId"/>
>> </relation>
>> <relation type="one-nofk" rel-entity-name="WorkEffortPurposeType">
>> <key-map field-name="workEffortPurposeTypeId"/>
>> </relation>
>> </extend-entity>
>>
>> As a further test, I commented these out from jobshop and I copied this
>> extend-entity into the same entitymodel_view.xml file as the the
> definition
>> for WorkEffortAndPartyAssign in the workeffort project and got exactly the
>> same error.
>>
>>
>> -----Original Message-----
>> From: Jacques Le Roux [mailto:[hidden email]]
>> Sent: Thursday, May 30, 2013 6:38 AM
>> To: [hidden email]
>> Subject: Re: But in CategoryTree.groovy
>>
>>
>> Thanks for report Skip,
>>
>> BTW you must have missed something, findAll does not exist anymore for 3
>> years ;)
>> http://svn.apache.org/viewvc?view=revision&revision=938947
>>
>> Using
>> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
>> false);
>> Should be the way. Could you please confirm before I commit?
>>
>> Thanks
>>
>> Jacques
>>
>> From: "Skip" <[hidden email]>
>>> There is a line at 50 that sez:
>>>
>>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>>
>>> This causes a groovy ambiguious error when you go to the catalog screen
> in
>>> 12.04.
>>>
>>> Changing this to:
>>> prodCatalogs = delegator.findAll("ProdCatalog");
>>>
>>> Fixes the problem.
>>>
>>> I expect you guys already did this, there here it is for any others like
>> me
>>> that just download the zip file.
>>>
>>> Skip
>>>
>>
>

SkipDever

RE: But in CategoryTree.groovy

Created at OFBIZ-5210

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Monday, June 03, 2013 12:14 PM
To: [hidden email]
Subject: Re: But in CategoryTree.groovy

Thanks for report Skip,

So we lost a functionality, would you mind opening a Jira for that?

Thanks

Jacques

From: "Skip" <[hidden email]>
> view-entity used to be able to be extended. I used it in several places
in
> 9.x. They are supposed to be extendable currently in entitymodel.xsd.
>
> However, if you extend one, you get a runtime error about the base
> view-entity not existing even when the base entity and the extended one
are

> in the same file.
>
> Not a big deal as I just modified your view, but I like to keep my changes
> in hot-deploy to make upgrading easier.
>
> Skip
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Saturday, June 01, 2013 2:29 PM
> To: [hidden email]
> Subject: Re: But in CategoryTree.groovy
>
>
> Adrian said it's possible, since there are no OOTB examples I'm not so

sure

> (I never tried IIRW)
> Here are 3 years old answers which might help
>
> http://markmail.org/message/4d3gjql3xkuifmrg
>
> Jacques
>
> From: "Skip" <[hidden email]>
>> BTW
>>
>> There is still another bug. I am probably the only one that uses it, but
>> you cannot extend a view entity. Give it a try. I detailed it pretty
>> thoroughly in a previous email. It is repeated here:
>>
>> As a test, I extended OrderHeaderAndItems in a different module in

exactly

>> the same way and got the same error.
>>
>> Here is the extend that is causing the error. It is exactly the same as
> my
>> 9.x version which works fine:
>> <extend-entity entity-name="WorkEffortAndPartyAssign">
>> <relation type="one-nofk" title="Current"
>> rel-entity-name="StatusItem">
>> <key-map field-name="currentStatusId"
>> rel-field-name="statusId"/>
>> </relation>
>> <relation type="one-nofk" rel-entity-name="WorkEffortType">
>> <key-map field-name="workEffortTypeId"/>
>> </relation>
>> <relation type="one-nofk" rel-entity-name="WorkEffortPurposeType">
>> <key-map field-name="workEffortPurposeTypeId"/>
>> </relation>
>> </extend-entity>
>>
>> As a further test, I commented these out from jobshop and I copied this
>> extend-entity into the same entitymodel_view.xml file as the the
> definition
>> for WorkEffortAndPartyAssign in the workeffort project and got exactly

the

>> same error.
>>
>>
>> -----Original Message-----
>> From: Jacques Le Roux [mailto:[hidden email]]
>> Sent: Thursday, May 30, 2013 6:38 AM
>> To: [hidden email]
>> Subject: Re: But in CategoryTree.groovy
>>
>>
>> Thanks for report Skip,
>>
>> BTW you must have missed something, findAll does not exist anymore for 3
>> years ;)
>> http://svn.apache.org/viewvc?view=revision&revision=938947
>>
>> Using
>> prodCatalogs = delegator.findList("ProdCatalog", null, null, null, null,
>> false);
>> Should be the way. Could you please confirm before I commit?
>>
>> Thanks
>>
>> Jacques
>>
>> From: "Skip" <[hidden email]>
>>> There is a line at 50 that sez:
>>>
>>> prodCatalogs = delegator.findByAnd("ProdCatalog");
>>>
>>> This causes a groovy ambiguious error when you go to the catalog screen
> in
>>> 12.04.
>>>
>>> Changing this to:
>>> prodCatalogs = delegator.findAll("ProdCatalog");
>>>
>>> Fixes the problem.
>>>
>>> I expect you guys already did this, there here it is for any others like
>> me
>>> that just download the zip file.
>>>
>>> Skip
>>>
>>
>

varun

Order status not changing

In reply to this post by Jacques Le Roux

CONTENTS DELETED

The author has deleted this message.