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 cromwell...@gmail.com wrote:
Patrick,
Are you using an
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
Bob is in transit today. We're working on a fix.
On Mon, Oct 4, 2010 at 9:07 AM, Patrick Julien pjul...@gmail.com wrote:
Bob,
any suggestions for a work around for the moment?
On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien pjul...@gmail.com wrote:
For the editor part, I can see in the
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 cromwell...@gmail.com wrote:
Any relational
https://jira.springsource.org/browse/ROO-1488
On Mon, Oct 4, 2010 at 11:13 AM, Ray Ryan rj...@google.com wrote:
Bob is in transit today. We're working on a fix.
On Mon, Oct 4, 2010 at 9:07 AM, Patrick Julien pjul...@gmail.com wrote:
Bob,
any suggestions for a work around for the moment?
Thanks Sam, yeah, this is a big bad bug.
On Sun, Oct 3, 2010 at 9:33 PM, Sam Gross colesb...@gmail.com 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
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.ListString paths) {
}
is completely empty
but in this case, EditorContainer contains OfficeEditor because it's a
Bob,
any suggestions for a work around for the moment?
On Mon, Oct 4, 2010 at 9:41 AM, Patrick Julien pjul...@gmail.com 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,
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
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 to
The following test case passes:
public void testCollectionSubProperties() {
delayTestFinish(DELAY_TEST_FINISH);
simpleFooRequest().getSimpleFooWithSubPropertyCollection().with(
selfOneToManyField.fooField).fire(new ReceiverSimpleFooProxy() {
@Override
public void
On Mon, Oct 4, 2010 at 5:32 PM, BobV b...@google.com 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,
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 ListOffice offices; }
class Office { private ListPhone phones; }
practive is unique and has a list of offices
What I get back has all the practice seeded.
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
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 cromwell...@gmail.com wrote:
Any relational (non-value fields) are by default not sent back with a
request, you must request them with the
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
On Sun, Oct 3, 2010 at 7:24 PM, Patrick Julien pjul...@gmail.com 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
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 pjul...@gmail.com wrote:
Getting there.
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 pjul...@gmail.com wrote:
No, it's not just
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
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
21 matches
Mail list logo
