Is it possible...SCRATCH THAT...Is it reasonable and useful to add a bool to the DataPortal.XChild calls so that you can control whether it goes across the barrier or not? Wouldn't that make things simpler. No forcing us to use Creator patterns?
Personally I find it very confusing that DataPortal calls don't cross the dataportal?? Wouldn't it make more sense to have the portal say "hmmm I know I am on the client...let me cross over unless the person specifically says no do it locally". Not sure if it is related but there was a RunLocal attribute that handled that.
Getting way to complex for me to track let alone those I am going to be training. Conversation goes like this:
Me - "Because this is a child dataportal call you DON'T cross the dataportal so you have to use a ReadOnly or a CommandObject like a creator to ACTUALLY cross the dataportal. THEN you call the child dataportal method. The child dataportal methods just stay on whichever side they are called"
Them - "But it says DataPortal.ChildCreate. Why doesn't it use the dataportal?"
Me - "I know but it's not actually using the portal part of the portal...its setting MarkAsChild for you automatically and other stuff."
Them - <blank stare> "This is confusing"
Sorry, maybe just showing my ignorance and theirs at the same time by raising this question :-)
Assuming it is NOT practical/helpful etc.
My option is to code a normal DataPortal_Fetch etc. on the child object and then:
- markaschild() do i do this on return or before that while it is in its dataportal method?
- anything else?
Mostly this will be for Creates and Fetches especially for lazy loading.
I just can't get over creating a creator for every child object. I know I know
I really the "Using CSLA 4" ebooks. All 4 first books in the series + whichever UI techbology you use.
Your scenario is typical for "lazy loaded" objects or objects that need to get to the server for initialization.
In these circumstances you must use the DataPortal.Fetch or Create to pass tiers and call MarkAsChild on the object.
Copyright (c) Marimer LLC