An item that has been added to a toMany section can no longer be edited.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Have a detail page that contains a toMany listing.
2.  Add a new item in its detail page and save.
3.  Clicking on the item in the summary toMany list does nothing, and the right 
arrow (forgetting 
the name) is not there.

What is the expected output? What do you see instead?
I would expect to have the already added items editable.

What version of the product are you using? On what operating system?
0.11

Please provide any additional information below.

Original issue reported on code.google.com by nukemh...@gmail.com on 25 Apr 2010 at 1:00

[GoogleCodeExporter]

Okay.  I've been digging through the code, and I think I've got a very loose 
understanding of what is happening.

First, the accessory and editingAccessoryTypes are both set to None in 
CDLToManyRelationshipTableRowController 
tableView:cellForRowAtIndexPath:.  That's the minor point, though.

It appears that there is no corresponding 
CDLToManyRelationshipEditExistingObjectTableRowController, which would serve 
much like 
CDLToManyRelationshipAddNewObjectTableRowController.  There would be an 
equivalent method tableView:didSelectRowAtIndexPath:, in 
which CDLToManyRelationshipEditExistingObjectEditController would be created 
and pushed on the navigationController stack.

I've tried to walk through how everything is set up and subsequently called.  I 
think if I had a handle on that, then I'd be able to modify the code 
accordingly.  But there's a whole lot going on here that I'm really not 
tracking clearly.  Do you have a workflow document and/or diagram that I 
can take a look at that would help me with this?  If so, then I can try to add 
the appropriate code and submit it to you for your analysis.

This is pretty important stuff for me.  I need to be able to view/edit existing 
toMany detail pages.  Otherwise they're pretty much useless.  Which 
makes this library a non-starter.  Which would suck, because it has greatly 
simplified so much of what I've been doing.  There are other things 
that I want to add, too.  But those are nice-to-haves, which I can work on at 
my leisure.  This is a show-stopper, unfortunately.

Let me know if I can help.  I'll keep digging through the code.  I'm sure part 
of my lack of comprehension is a combination of the hour and the 
mental fatigue I've brought upon myself.  Maybe a fresh look tomorrow will 
bring new light to the situation.

Original comment by nukemh...@gmail.com on 25 Apr 2010 at 2:38

[GoogleCodeExporter]

This is a feature that I had planned for the next release - I didn't have 
enough time 
to get it ready for the initial release.

About a workflow diagram, I don't have one specifically, but most tableView 
delegate 
or datasource methods (excluding a few lesser used ones) are "passed" down 
through 
the DetailView -> SectionController -> RowController (the most specific class's 
implementation is taken (aka row over section or detail, section over detail, 
etc).

I was planning to implement the didSelectRow and willSelectRow methods in 
CDLToManyRelationshipTableRowController to allow the rows to be selected during 
edit 
mode.  From the didSelect, I planned to push another detailView controller 
configured 
by a user specified property list file.  You would also have to make the 
changes you 
have mentioned about the editing accessory.  

The implementation should be pretty straightforward - if you do implement it, 
I'll 
integrate your code into the next version.  Let me know if the above makes 
sense.

Original comment by epe...@gmail.com on 25 Apr 2010 at 7:06

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I stepped through the code in the debugger for what must have been 2 hours last 
night, and am getting a better 
understanding of what is going on.  I've seen most of what you're talking about 
as far as the "pass down" mechanisms.  
Pretty intense.  I'm still missing where some of the setup is happening.  When 
the dictionaries are passed in, the section 
and row controllers are created, but I'm still missing a couple of steps where 
the specific ones are being instantiated and 
added to the controller array.  I was probably just too tired to really grok it.

I'll dink around in the code today and see if I can get some basic stuff set 
up.  Just to prove I'm messing with the right code!

I'll keep you posted.  If you see a mushroom cloud rising over Northern 
Maryland, you'll know why! ;-)

Original comment by nukemh...@gmail.com on 25 Apr 2010 at 7:50

[GoogleCodeExporter]

CDLTableSectionController and RowController have class methods that are called 
by the 
detailView and the sectionControllers respectively to create those controllers.
{{{
+ (id<CDLTableSectionControllerProtocol>) 
tableSectionControllerForDictionary:(NSDictionary *) sectionInformation 
forDelegate:(id<CDLTableSectionControllerDelegate>) delegate

+ (id<CDLTableRowControllerProtocol>) 
tableRowControllerForDictionary:(NSDictionary 
*) rowInformation forDelegate:(id<CDLTableRowControllerDelegate>) delegate
}}}

Original comment by epe...@gmail.com on 25 Apr 2010 at 8:00

• Changed state: Accepted

[GoogleCodeExporter]

Hmm.  Okay.  I've touched a few files, and had to do some refactoring, and all 
of the current code seems to be working.  But 
CDLToManyRelationshipTableRowController seems to be losing track of some of the 
data in the sectionController.  As a result, the plist for the DetailView 
that is supposed to be loaded when my new 
CDLToManyRelationshipEditExistingObjectEditController is instantiated is hosed. 
 Which hoses everything 
else.

When I click on "Add New ...", however, everything works fine.

Here's a list of what I modified/added:

CDLToManyRelationshipEditExistingObjectEditController.h: // CREATED-START:  GSH 
2010-04-25
CDLToManyRelationshipEditExistingObjectEditController.m: // CREATED-START:  GSH 
2010-04-25

CDLToManyRelationshipTableRowController.m: // ADDED-START:  GSH
CDLToManyRelationshipAddExistingObjectsTableRowController.m: // ADDED-START:  
GSH
CDLToManyOrderedRelationshipAddTableRowController.m: // ADDED-START:  GSH
CDLRelationshipTableRowController.m:    // ADDED:  by GSH 2010-04-24
CDLToManyOrderedRelationshipAddTableRowController.h:    // ADDED-START:  GSH
CDLToManyRelationshipTableRowController.h: // ADDED-START:  GSH
CDLToManyRelationshipAddExistingObjectsTableRowController.h: // ADDED-START:  
GSH

ADDED means I've added a change to that code.  I notate where REFACTORing 
occurs.  CREATED indicates the file has been created new.

I moved sectionController up to CDLToManyRelationshipTableRowController.m|h as 
that the root for everything that is using sectionController.  I don't 
understand why the subclasses work fine, but 
CDLToManyRelationshipTableRowController seems to get lost in the fog.

If you want to look at my code files, let me know.  I'll send them to you.  I 
think I'm really close.  But I'm still vague enough with the details that I'm 
really 
not sure.

Original comment by nukemh...@gmail.com on 25 Apr 2010 at 10:30

[GoogleCodeExporter]

Okay.  I've been wallowing in the debugger, tracing the code as it wends its 
way through CDL.  Something interesting has come to my attention.  It directly 
relates to comment 5 
above.

In CDLDetailViewController, initForPropertyList:managedObject: gets executed to 
initialize everything from the property list.  loadedStructure gets created 
from the plist, and 
then a for-loop iterates through it to create each section.  The following line 
is executed each time:

id<CDLTableSectionControllerProtocol> aSectionController = 
[CDLTableSectionController tableSectionControllerForDictionary:sectionInfo 
forDelegate:self];

When I follow the trace inside of 
tableSectionControllerForDictionary:forDelegate:, there is a switch that gets 
executed.  For the enum value 
CDLTableRowTypeToManyRelationship, newTableSectionController is loaded using 
[[CDLToManyRelationshipSectionController alloc] 
initForRowDictionaries:rowDictionaries 
forSectionTitle:aSectionTitle forDelegate:delegate].  Inside of 
initForRowDictionaries:..., all of the pertinent instance variables are set 
properly.  However, as soon as the 
assignment to newTableSectionController is set, most of them become out of 
scope!!!!  Which then impacts the rest of the functionality, in particular 
related to being able to 
click on that row and view the detailview.

I hope this makes sense.  I don't understand why this occurs, as it looks like 
everything else works perfectly.  I'm sure I'm missing something obvious, but 
I'm stumped at the 
moment.  If you have any leading questions that will help me look at this 
differently, I'm all ears/eyes.  And I'll send you the source if you want it.  
I've tried to comment it as 
clearly as possible any place I've touched it.

Lemme know what you want to do.

Original comment by nukemh...@gmail.com on 27 Apr 2010 at 1:36

[GoogleCodeExporter]

Which variables can't you access and how do you try to access them?  Can you 
shoot me
your code (no promises I can look at for a day or two though, I'm swamped with 
life)

Original comment by epe...@gmail.com on 27 Apr 2010 at 1:49

[GoogleCodeExporter]

I'm looking at them in the debugger, which may actually explain why they're 
"out of scope".  The debugger is 
showing the private ivars, rather than the properties.  That may be why it 
shows up that way.

But the problem that I seem to be having is that at least some of the 
properties are, in fact, not showing up, 
even though they get populated in initForRowDictionaries:....  For example, as 
I point out in #5, the plist for 
the detailviewcontroller just goes "poof".  So, when the controller tries to 
populate itself based on the details 
from the plist, it bombs.

I'll zip everything up and get it to you shortly.

Original comment by nukemh...@gmail.com on 27 Apr 2010 at 2:27

[GoogleCodeExporter]

Here's a zip with everything I think I've touched.  Plus a couple of my files, 
so you can see how I'm trying to use 
the code.  Let me know if you have any questions.

Original comment by nukemh...@gmail.com on 27 Apr 2010 at 2:36

Attachments:

• Archive.zip

[GoogleCodeExporter]

By the way, I've included the CDLRootViewController changes that I made.  Let 
me know what you think.

My first contribution to an open source project!  Wee!!!

Original comment by nukemh...@gmail.com on 27 Apr 2010 at 2:40

[GoogleCodeExporter]

OK will look at this later this week - thanks!

Original comment by epe...@gmail.com on 27 Apr 2010 at 3:38

[GoogleCodeExporter]

Have you had a chance to dig into this at all?  I've run through your code a 
few times since, and am still not quite 
getting it.  I think I'm missing something fundamental in how you're 
architecting things, but I can't even get to 
the point of being able to ask the right questions.  Of course, looking at this 
code after midnight surely isn't 
helping matters!

By the way, I messed something up with CDLRootViewController.  I commented out 
your modal push, so it was 
disabling the pop when saving from the lower level.  I figured it out today, 
and fixed it.  I'll get you a fresh copy 
tomorrow.

Original comment by nukemh...@gmail.com on 1 May 2010 at 4:37