r8965 fixed the remaining issue. The other issue was on the AutoBean
itself and was previously fixed. However, I believe I have found
another issue in AbstractAutoBean which I just posted.
On Thu, Oct 7, 2010 at 4:57 PM, Ray Cromwell wrote:
>
> Patrick,
> Are you using an ORM like hibernate
Patrick,
Are you using an ORM like hibernate or JDO? One of my concerns is, unless
you wrap the entire request in an transaction, the result of any find()
calls within JsonRequestProcessor are going to be detached objects.
Different ORMs have different pre-fetched semantics, for example, some of
The editor framework can give you the info for the with calls, but it's up
to you to use it. If you want everything, put the contents of
RequestFactoryEditorDriver.getPaths() into your with() call.
On Sun, Oct 3, 2010 at 4:10 PM, Ray Cromwell wrote:
>
> Any relational (non-value fields) are by d
https://jira.springsource.org/browse/ROO-1488
On Mon, Oct 4, 2010 at 11:13 AM, Ray Ryan wrote:
> Bob is in transit today. We're working on a fix.
>
>
> On Mon, Oct 4, 2010 at 9:07 AM, Patrick Julien wrote:
>
>> Bob,
>>
>> any suggestions for a work around for the moment?
>>
>>
>> On Mon, Oct 4,
Bob is in transit today. We're working on a fix.
On Mon, Oct 4, 2010 at 9:07 AM, Patrick Julien wrote:
> Bob,
>
> any suggestions for a work around for the moment?
>
>
> On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien wrote:
> > For the editor part, I can see in the generated code for my editor
At the moment we always fetch all non-entities, and only treat with() as
additive, to add related entities into the mix.
I'm a bit concerned about that, actually. With the RF overhaul we no longer
have a client side cache to confuse things, so I wonder if we should try to
get sparse DTOs in place
OK, this also works for me, where it breaks down is more collections
So I go back to practice, offices and phones
class Practice { private List offices; }
class Office { private List phones; }
practive is unique and has a list of offices
What I get back has all the practice seeded. All the off
On Mon, Oct 4, 2010 at 5:32 PM, BobV wrote:
> Your feedback has been very helpful in finding out where the weak
> points in our APIs and implementations are.
>
>> driver.getPath() isn't able to completely scan an editor tree when it
>> contains CompositeEditor's that, they themselves, have more ed
I don't know what to tell you, I'm going to have to look at this again
because it just does not work for me
On Mon, Oct 4, 2010 at 5:46 PM, Ray Cromwell wrote:
>
> The following test case passes:
> public void testCollectionSubProperties() {
> delayTestFinish(DELAY_TEST_FINISH);
> simple
The following test case passes:
public void testCollectionSubProperties() {
delayTestFinish(DELAY_TEST_FINISH);
simpleFooRequest().getSimpleFooWithSubPropertyCollection().with(
"selfOneToManyField.fooField").fire(new Receiver() {
@Override
public void onSuccess(SimpleFo
Your feedback has been very helpful in finding out where the weak
points in our APIs and implementations are.
> driver.getPath() isn't able to completely scan an editor tree when it
> contains CompositeEditor's that, they themselves, have more editors in
> their hierarchy
I'm thinking about how t
As an update to this issue, I can confirm that I have an editor
working in another scenario where the depth level doesn't go beyond,
well, 1 I guess.
So I an editor, and it has a list in it but the list doesn't contain
other EntityProxy's
The two issues still remain:
driver.getPath() isn't able
Bob,
any suggestions for a work around for the moment?
On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien wrote:
> For the editor part, I can see in the generated code for my editor that
>
> public static void traverseEditor(com.*.client.ui.EditorContainer
> editor, String prefix, java.util.List pa
For the editor part, I can see in the generated code for my editor that
public static void traverseEditor(com.*.client.ui.EditorContainer
editor, String prefix, java.util.List paths) {
}
is completely empty
but in this case, EditorContainer contains OfficeEditor because it's a
composite. Offi
Thanks Sam, yeah, this is a big bad bug.
On Sun, Oct 3, 2010 at 9:33 PM, Sam Gross wrote:
> I also ran into a bug today where sub entities were not always
> deserialized. The problem is in that entries in related objects may
> refer to entities that haven't been deserialized yet if the referenc
I also ran into a bug today where sub entities were not always
deserialized. The problem is in that entries in related objects may
refer to entities that haven't been deserialized yet if the referenced
entities occur later in related objects.
Splitting AbstractRequestContext.processReturnRecord s
I'm still having difficulties even with this syntax, again the
collections seem to be the problem
so having "offices" give me back all my offices.
but putting "offices.address", or "offices.office.address" or
"office.address" still gives me null
On Sun, Oct 3, 2010 at 9:07 PM, Ray Cromwell wrot
the syntax of with() is with("property.subProperty.subSubProperty",
"property2.subProperty2.subPropertyProperty2"). Bob can answer the question
as to how to make deeply composited editors do the right thing.
On Sun, Oct 3, 2010 at 6:02 PM, Patrick Julien wrote:
> No, it's not just me, anything
No, it's not just me, anything one level deep doesn't get picked up.
So my offices also have on address and it's not in the getPath() array
either. Even if it was, what's the syntax for sub path elements?
On Sun, Oct 3, 2010 at 8:38 PM, Patrick Julien wrote:
> Getting there. So now getPaths()
Getting there. So now getPaths() gets me the data for my offices and
patients but not the phones inside the offices.
Since offices is using my own composite editor, I'm going to assume
that's where the problem is
On Sun, Oct 3, 2010 at 8:22 PM, BobV wrote:
> On Sun, Oct 3, 2010 at 7:24 PM, Patr
On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien wrote:
> Yeah, because even with using with(). The problem is the entire
> object graph isn't there
>
> So I have a practice that has offices and each office has phones.
>
> So if I ask for offices. It fills in the offices but the phones
> inside it
Yeah, because even with using with(). The problem is the entire
object graph isn't there
So I have a practice that has offices and each office has phones.
So if I ask for offices. It fills in the offices but the phones
inside it are not. This could get laborious if I need to do this
manually f
Is there a wildcard value? I don't want the all the fields when
listing but when I go in edit details, I do
On Sun, Oct 3, 2010 at 7:10 PM, Ray Cromwell wrote:
>
> Any relational (non-value fields) are by default not sent back with a
> request, you must request them with the with() method, e.g.
Any relational (non-value fields) are by default not sent back with a
request, you must request them with the with() method, e.g.
with("superVisor"). Just because you sent some object over with that field,
doesn't mean that the field will also be returned to you, because a method
could potentially
I'm getting used to this editor framework and I like it a lot,
unfortunately, I think I've stumble upon a blocker for me.
EntityProxy's that contain collections are not being filled in. So
you can send up an object graph in one shot in order to save it.
Which is great.
Unfortunately, on return,
25 matches
Mail list logo
